Update serde dependency to 1.0

[DenisKolodin]

These changes updates serde dependency from 0.9 to 1.0 line.
Only root sources updated (no updates in sub-crates).
I added lifetimes to Deserialize trait implementations and use ownership instead of mutable reference.
Also I used associated types for results.

I see that there is #296, but that PR updates url_serde only (that's why I haven't updated sub-crates).

I've runned/passed all tests and checked it as dependency for my own project.

---

This change is 

[SimonSapin]

Thanks for you work, but I won’t be taking this pull request.

serde is a public dependency, so changing it to an incompatible version is a breaking change that must be reflected in the crate’s own version number. For the url crate, that would make it version 2.0.0. This in turn would require every library that depends on url (such as Hyper for example) to make a breaking-numbered version of their own in order to update url.

Because the disruption to the Rust ecosystem would be significant, I want to avoid making any breaking change to url until it becomes really necessary. This is why the url_serde crate exist: so that this separate crate can be updated independently of url.

[SimonSapin]

url_serde is now published with serde 1.0 support. See https://docs.rs/url_serde/0.2.0/url_serde/

[DenisKolodin]

@SimonSapin Sending a PR is a best way to understand something )
I've tried url_serde, it works fine. Thanks!
Could you explain me more about:

• If I understand correctly: it's better to have a separate crate for actively improving features than using feature dependency in crates, especially for popular crates. Is it right?
• Do you have any plan to release url:2.0.0? If so will it support serde:1.0.0 directly or through url_serde crate and dependency to serde will be removed from the root crate?

[SimonSapin]

The only reason for the separation is that adding support for serde 1.0 in url itself is difficult without removing support for older versions. Removing support for anything is a breaking change, which I’d rather avoid until there’s a stronger reason to justify it.

url 2.0 will probably happen some day. I’m still somewhat undecided on what will be the best approach then.