Derive derive attributes

[clux]

Currently we have hardcode the derives to the root struct (["Serialize", "Deserialize", "Clone", "Debug"], and allow a few extra ones using proc macro arguments:

#[derive(CustomResource, Serialize, Deserialize, Debug, PartialEq, Clone)]
#[kube(
    group = "clux.dev",
    version = "v1",
    kind = "Foo",
    status = "FooStatus",
    PartialEq
)]
pub struct MyFoo { ... }

This PartialEq argument (from #242) allows mutating this derive list slightly, but not more than appending, and not more than that particular trait. Not an ideal solution.

Ideally, the proc macro should be able to identify certain traits derived for this sub struct (the spec) and apply them to the created object. The proc macro crate SHOULD give access to this information at the very least through the token tree, but it's a pain to figure it all out.

Logic could be a little something like:

if derive_attrs.contains("PartialEq") {
  derives.push("PartialEq")
}

(Hopefully, it's easy to access the particular #[derive] attrs - because if it is, we could just parse them like we parse the #[kube] metas.)

But there are big complications w.r.t. error handling; in particular to relations of FooStatus - a struct which we do not know if they implement these traits. It might not be possible to provide good errors for this if we ask to auto-derive, and FooSpec has PartialEq, but FooStatus does not. That will fail with the usual compile error (or worse). It is possible that this isn't something we should auto-derive but instead have a named vector argument for instead:

#[kube(derive = PartialEq, derive = ExtraTrait)]

Not sure what solution is best atm, but I would like an easy to use one with good defaults. I had to propagate Debug everywhere in my code earlier because deriving CustomResource depended on it, and it's not a nice first step. If we auto-derived, we could push Debug into one of those traits that we'll add if the spec struct wants it.

[clux]

New attr released in kube-derive 0.35.0