Explicitly specify the serde/derive dev-dependency

[musicinmybrain]

In downstream packaging for Fedora, we routinely patch out dev-dependencies on criterion because they are unnecessary (we run tests, but not benchmarks) and bring in a large tree of otherwise-unnecessary dependencies.

It turns out that dropping the criterion dev-dependency by removing this line from Cargo.toml

tera/tera/Cargo.toml

Line 45 in f345cf2

criterion = "0.8"

breaks compiling the tests and examples, with many errors like:

error: cannot find derive macro `Serialize` in this scope
 --> examples/teams.rs:5:10
  |
5 | #[derive(Serialize)]
  |          ^^^^^^^^^
  |
note: `Serialize` is imported here, but it is only a trait, without a derive macro
 --> examples/teams.rs:1:5
  |
1 | use serde::Serialize;
  |     ^^^^^^^^^^^^^^^^
help: consider importing this derive macro
  |
1 + use serde_derive::Serialize;
  |

This is because tests and examples rely on the derive feature of the serde crate (not just having serde_derive in the dependency tree, although the explicit dependency on it is correct since serde_derive::Serialize is used directly), but there’s no (dev-)dependency on serde with the derive feature. Instead, criterion happens to depend on serde/derive, so it gets enabled due to feature unification.

To be more explicit about this requirement, to guard against possible changes in the features used by criterion or perhaps a future switch to a different benchmarking library, and to make downstream packaging easier, this PR adds an explicit dev-dependency on serde/derive.

[musicinmybrain]

@decathorpe pointed out that with the serde/derive dev-dependency properly specified, it’s no longer necessary to use and depend on serde_derive directly, and that this would eliminate the need to update serde and serde_derive in lockstep. I pushed a follow-up commit implementing that suggestion.

[Keats]

Thanks!