Make `--derive` more flexible

[MathiasPius]

Fixes #231

This overhauls the --derive flag in a backwards compatible way, allowing users to specify traits to derive on a per-object basis, on all structs, all enums, or just unit-only enums.

From the updated help text:

-D, --derive

Derive these additional traits on generated objects

There are three different ways of specifying traits to derive:

1. A plain trait name will implement the trait for all objects generated from the custom resource definition: --derive PartialEq

2. Constraining the derivation to a singular struct or enum: --derive IssuerAcmeSolversDns01CnameStrategy=PartialEq

3. Constraining the derivation to only structs (@struct), enums (@enum) or unit-only enums (@enum:simple), meaning enums where no variants are tuple or structs: --derive @struct=PartialEq, --derive @enum=PartialEq, --derive @enum:simple=PartialEq

   See also: https://doc.rust-lang.org/reference/items/enumerations.html

I'm still not entirely sure if the enum:simple syntax is the right way to go. I experimented with inverting it so enum matched only the simple enums, and you had to do enum+complex to trigger derivation for complex types, but that was even less intuitive since you would expect enum to cover all enums by default.

[MathiasPius]

Seem to have lost some code during a rebase, hang tight!

[MathiasPius]

That should do it. Let me know what you think!

[MathiasPius]

I think this looks great. Thanks a lot for doing this! I see nothing major implementation-wise here i disagree with. Some minor nits inlined (that are largely ignoreable).

One point on maintainability though; tests for this would be helpful. I also think this is self-contained enough that it could live inside a derive.rs module that can be tested therein. That way the only part from this that really needs to live inside of main.rs is the loop over self.derive that decides whether s gets derives (and even that can possibly also be parametrised inside the derive module by passing the s by ref in there, but that's just a stray thought).

LMK what you think.

Putting it in its own module makes a lot of sense, I avoided doing it because the rest of the project seemed to favor localized code over modularization. I'll try and extract it and see how testability can be written into it.

[MathiasPius]

I think that should be it!