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!

[clux]

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.

[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!

[clux]

Very clean and separated now. Thanks a lot. I'll leave it here for a day just in case in case anyone else likes to chime in (also left an optional nit) but this is very simple to reason with now and happy to just send this out as is.