Migrate serde dependency to use derive feature

[veeg]

This is in line with best practices recommended by serde[1].
This will also resolve downstream crates depending on shiplift who enable the
serde derive feature, due to Cargos unification of features for each crate[2].

Example of the problem for downstream crates:

$ cargo new deptest
$ cd deptest
$ echo 'shiplift = "0.4"' >> Cargo.toml
$ echo 'serde = { version = "1.0", features = ["derive"] }' >> Cargo.toml
$ cargo build

This will result in the following error:

error[E0252]: the name `Serialize` is defined multiple times
 --> /home/veeg/.cargo/registry/src/github.com-1ecc6299db9ec823/shiplift-0.4.0/src/builder.rs:5:5
  |
4 | use serde::Serialize;
  |     ---------------- previous import of the macro `Serialize` here
5 | use serde_derive::Serialize;
  |     ^^^^^^^^^^^^^^^^^^^^^^^ `Serialize` reimported here
  |
  = note: `Serialize` must be defined only once in the macro namespace of this module
help: you can use `as` to change the binding name of the import
  |
5 | use serde_derive::Serialize as OtherSerialize;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

What did you implement:

Closes: #xxx

How did you verify your change:

cargo build && cargo test

What (if anything) would need to be called out in the CHANGELOG for the next release:

[softprops]

Thanks for the patch. I've started noticing this pop up in other crates. Since serde is such a common crate it tends to have a ripple effect across the ecosystem :)

[veeg]

I fell into this rabbit hole and had to figure out the cargo feature story. Hopefully they will make the huge refactoring work needed in cargo to split crate units by features enabled. I can image this issue with serde and how widespread it is will accelerate this process.

[softprops]

published a new release including this pr https://github.com/softprops/shiplift/blob/master/CHANGELOG.md#050