Explicitly depend on serde_derive

[Veykril]

serde depending on serde_derive increases our compile times by a good chunk which is unfortunate as that doesn't have to be the case.

This PR explicitly changes that for our workspace members, though unfortunately the following dependencies still activate that feature for us:

• camino v1.1.4
• cargo-platform v0.1.2
• cargo_metadata v0.15.3
• lsp-types v0.94.0
• url v2.3.1

And I am unsure whether these libraries are open to changing that.

[lnicola]

Does this make cargo build serde_derive earlier?

[Veykril]

No this would make cargo build serde earlier, as it no longer needs to wait for serde_derive to build (just so serde can re-export the derive attributes).

That is if we can get the library authors of the listed crates change this as well.

[lnicola]

Typo?

[Veykril]

The ::{self} is actually required (it explicitly only imports the type namespace), without it this will import both the derive attribute and the trait, while we already have the derive attribute in scope via the serde_derive::Deserialize import (which is only the case because the derive feature is still enabled thanks to the deps).

I'll move this PR to draft though and wait until we can maybe get our deps to move, then we don't need these path shenanigans.

[Veykril]

Turns out using derive is recommended as the crates break if serde and serde_derive don't have the same version number 🙃 Oh well

[matklad]

I think we can do that with https://github.com/matklad/macro-dep-test

I mean, serde might up doing that upstream, but, even before that, I think we ourselves can depend on serde with derive feature enabled under any() cfg. That’ll bind the versions of any existing serde release.