Remove requirement on bitvec for std feature and constructing TypeDefBitSequence.

[jsdw]

Requires Rust 1.60 for the optional dependency feature (? in Cargo.toml).

• Use the "?" feature in cargo.toml features to avoid bringing bitvec in when the "std" feature is enabled, unless it's been specifically asked for. I don't believe that this is a breaking change, since while the bitvec crate would be included if just the "std" feature was enabled and isn't now, it looks like we hide that stuff behind an explicit "bit-vec" feature anyway, so hopefully it just avoids pulling in a crate we don't actually use in that case.
• Allow TypeDefBitSequence::new() to be called without the bit-vec feature being enabled. This relaxes the constraints on it slightly, making "incorrect" uses more possible, but allowing us to create the type info without expecting any specific underlying library. Again, since this just relaxes/adds, it's not a breaking change.

I also updated the UI test output just because it had changed a touch. There are a couple of unused lifetime warnings that can't be silenced but will be silencable in a future rust update (see rust-lang/rust#96956)

parity-scale-codec PR to help with this: paritytech/parity-scale-codec#375

Closes #167

[jsdw]

The bitvec crate will no longer be pulled in when "std" is enabled, but this I think makes no difference to the external interface since bitvec additions are behind the separate "bit-vec" feature anyway.

[ascjones]

Note that bitvec will still ultimately be pulled in via scale/std https://github.com/paritytech/parity-scale-codec/blob/b5f2b360e2939e8a235423f40591db09e879fdbb/Cargo.toml#L41

[jsdw]

Ooh ok; I'll do a quick follow PR there then to prevent that :)

[jsdw]

PR for parity-scale-codec thing: paritytech/parity-scale-codec#375

[dvdplm]

…or else? :)
Like, is "recommended" the right word here? Isn't it more "has to be"?

[jsdw]

I mean, in theory it can be whatever it wants; it's just that our current tooling won't know how to decode the thing if the types don't line up with what we expect (no reason somebody else can't make tooling that can support more exotic types though if they want to go that route)

[ascjones]

Note that bitvec will still ultimately be pulled in via scale/std https://github.com/paritytech/parity-scale-codec/blob/b5f2b360e2939e8a235423f40591db09e879fdbb/Cargo.toml#L41

[jsdw]

I'll merge this for now but ideally would make sure we bump the parity-scale-codec version (if needed) when that PR lands before releasing. Actually.. it doesn't matter.. we can do another release if needed.