Split out sealed traits instead of making them unsealable

[chrysn]

The unsealed_read_write feature that lifts the seals off Read and Write is convenient now, but I have doubts it's ideal with respect to maintaining stable versions: A crate that depends on serde_cbor/unsealed_read_write could only depend on a specific version for lack of API guarantees, and worse, libraries have indirect dependencies on serde_cbor/unsealed_read_write could inadvertently start using unsealed features.

The pattern I suggest is to have the Read/Write traits in a separate crate called serde_cbor_internals or similar (maintained in a workspace together with serde_cbor). That crate could stay eternally unstable, or just churn through stable numbers. Then regular (esp. std) users can have a long-stable serde_cbor = "^1" dependency, whereas someone implementing the "unsealed" trait would depend on serde_cbor_internals = ">=25, <32" that, when a serde_cbor_internals 32 is released, need to decide whether it'll be ">=32, <33" or ">=25, <33". (I doubt the version numbers would get that high, but anyway, allowing that is the point of sealing the trait).

serde_cbor could not pub use the traits (as that'd make its API change whenver the traits change), but could use the traits in its interfaces.

On the down side, this means that there wouldn't be a stable Write and Read trait over which users could be generic over, but I'm unsure how much that'd matter. It might be convenient to keep public sealed traits in serde_cbor (which can be used for generics and on the public interfaces) that are trivially implemented by the serde_cbor_internals traits, but there might be easier ways as well.