Figure out a way to support multiple versions of serde in-crate

[SimonSapin]

This is a requirement for doing #304 without a breaking change.

@dtolnay suggested a plan along these lines:

• Make a serde_1_0 crate that depends on serde 1.0 and only contains pub use serde::*;. Make other similar crates for other mutually-incompatible versions of serde. (I’d rather the serde project maintain these crates, if they’re willing.)
• Have url optionally depend on these crates, with Cargo feature flags named serde_1_0 etc.
• Implement multiple versions of the Serialize and Deserialize traits. For example impl serde_1_0::Serialize for Url {…} impl serde_0_9::Serialize for Url {…} etc.
• Publish a new, compatible version of url_serde that is marked #[deprecated] with a message that point to the feature flags.

Open question: can #[derive] be used in this setup? How?

These crates with a version number in the name are a hack to work around a limitation of Cargo: a crate can not depend on multiple crates with the same name. (That is, multiple mutually-incompatible versions of the same crate.) A better solution would be to make Cargo support that scenario directly. This probably involves locally renaming a dependency for disambiguating extern crate.

Help wanted to write a Cargo RFC.

[dtolnay]

Serde is willing to own the shim. I will send a PR to url once it's ready.

[SimonSapin]

@dtolnay Does something like #[derive(serde_1_0::Serialize)] work?

[dtolnay]

Yes but it would be nightly only.

[dtolnay]

#327 implements this using a legacy-serde shim and a serde1 shim.

[SimonSapin]

Closing as we’ll likely not do this. Instead we’ll eventually make rust-url 2.0 without support for serde versions other than 1.x. In the meantime https://crates.io/crates/url_serde is not idea but can be used.