Upgrade to value-bag 1.0.0-alpha.9 and remove by-value 128bit int conversions

[KodrAus]

This PR upgrades our value-bag version to 1.0.0-alpha.9, which includes a breaking change to how 128bit numbers are handled. Instead of storing them by-value we only store them by reference. Along with some other internal layout changes this reduces the size of Value from 48 to 24 bytes, which is a great saving for the stack-local arrays we create to hold them.

In practice this doesn't affect whether or not 128bit values can be used in the macros because they rely on the ToValue trait, which is always by-reference. I'd be keen to hear if anybody is relying on the From impls though.

I'm hoping to get this through sooner rather than later in case rust-lang/rust#95845 is merged in its current state that breaks constant type id comparison, which will mean shipping a patch to value-bag for nightly users.

r? @Thomasdezeeuw

[KodrAus]

We can work around the breakage if it's worth it by the way. I just carried it through to log because it seemed appropriate.

[Thomasdezeeuw]

LGTM.

I also took a quick the changes to sval and I think I found a breaking one in sval-rs/value-bag@3fb84ab#diff-2e9d962a08321605940b5a657135052fbcef87b5e360662bb527c96d9a615542R24-R25. It uses ? in enabling feature, which is 1.60+, while log still supports 1.31 (although we could bump that).

[Thomasdezeeuw]

Nit: final ,.

[KodrAus]

I think that macro implementation is a little iffy and it actually requires that trailing , 😄

[KodrAus]

It uses ? in enabling feature, which is 1.60+, while log still supports 1.31 (although we could bump that).

Ah well spotted! We actually only require the latest stable for the key-value API, so are ok to bump this. That feature is perfect for that library because it stitches together serialization APIs. Before I was wondering how I could ever introduce a new framework like valuable without exploding the crate graph, but now that's actually possible.