Support more serialization/deserialization targets: Deserialize into owned strings if "alloc" feature is enabled

[jsdw]

Currently bitvec will attempt to deserialize several things into borrowed strings, which will fail if the Deserializer calls visit_string() instead of visit_borrowed_string() for these things. This is the case with things like serde_json and serde_value, and probably any deserializers that themselves hold owned strings.

This PR tweaks the behaviour so that when the alloc feature is enabled, we deserialize into owned strings instead, allowing bitvec to be deserialized from popular formats like serde_json. When the alloc feature isn't enabled, we keep the existing behaviour roughly as-is.

What do you reckon @myrrlyn? :)

Closes #167

[jsdw]

Since the min supported rustc version for Bitvec is 1.56, this "?" features isn't available yet.
Removing it would mean that enabling the "alloc" features also enabled the "serde" feature. Any thoughts on how best to tackle this?

[myrrlyn]

In which version did this stabilize? While I had hoped to refrain from MSRV raises until I'm able to release 2.0 with the BitArray redesign, my MSRV policy does state that I may freely do so in the minor series.

If raising the MSRV to support optional transitive features really is sufficient (with the rest of this PR) to resolve the de/ser problem, then please raise MSRV in rust-toolchain.toml and README.md, and update to 1.1.0 in Cargo.toml.

I am going to continue working through my backlog in the 1.0 series. Thank you for your patience as I've ignored the project, and I look forward to releasing your 1.1 soon!

[myrrlyn]

While the text representation of type parameter tokens is very much a hack to try to ensure round-trip correctness, I would prefer to keep it if able. I don't have a better way offhand to encode this information (while type_name::<T>() isn't guaranteed to be stable across compiler versions, I don't believe type_id::<T>() is even guaranteed to be stable across compiler invocations), and I certainly don't want to try to enforce a global registry of BitOrder implementors within a compilation unit (especially since this wouldn't help in the case of two separate programs exchanging data with each other!).

I believe the easiest resolution is therefore just to accept this PR, lifting the MSRV and minor version as described in my response to your comment in Cargo.toml.

[jsdw]

Thanks for your feedback!

I bumped the MSRV to 1.60 anywhere I found it mentioned, and added a changelog entry and version bump for 1.1.0 :)

Lemme know if you'd like anything else tweaking before merging and I'll get on that!

[myrrlyn]

It looks like @/dtolnay fixed this in #185 without an MSRV bump by fixing misunderstandings I'd made about how serde operates. Thank you for your efforts and I apologize for taking so long to check my inbox that this got superseded.

[jsdw]

Oh not at all; that's excellent, and his PR looks far more comprehensive a fix than mine, so brilliant stuff!