Support deriving LabelledGeneric on enums

[Diggsey]

(Based off #157)

I reused the Field type to represent named enum variants.

This is just the first step - to make enums actually useful we'll need to:

• Support "taking", etc. by field name only.
• Implement a general-purpose "sculpt"-like function which works on HLists/Coproducts of Fields, and only uses the field's name to determine the sculpting to perform.
• Make this work recursively, so that you can re-order struct-like variants and the fields within those variants at the same time.

Another issue I found is the field! macro - the way it generates the field name is inconsistent due to limitations of the macro system (eg. field!((_, _0), ...) has the name __0 when it should be _0). It should be possible to implement it as a procedural macro, so that one can just write field!("_0", ...) and not have to worry about the encoding.

[Diggsey]

(Rebased and reformatted)

[lloydmeta]

Sorry for the delay in reviewing this a bunch of life things came up and I'm only currently catching up with work and other things. Just took an overall look at this PR, and it looks really good ! Will try to find some time over the weekend to give it a detailed review.

[Diggsey]

Yeah, for my own use case, the names of the variants are essential, as I'm using frunk to implement conversions between "similar" but separate data structures, and it allows me to generically convert from one enum to another.

The reason I did this was for two reasons:

• If you just care about the types, you could derive Generic instead of LabelledGeneric
• If you care about the field names but not the variant names, you could just map away the Field/Variant type easily enough.

However, if you think it would be worth adding all four combinations:

• Unlabelled
• Labelled fields
• Labelled variants
• Labelled fields and variants

Then that would also work.

My eventual goal is to implement something like "transmogrify" in that it uses the field names, but that can be "driven" by the return type. So instead of saying "map X to whatever F(X) happened to return", you could say "convert X to Y" and it would recursively:

• Map the field/variant names.
• Figure out the "from"/"to" types for each field or variant.
• Apply the correct instantiation of "F<From, To>" in order to perform the conversion.

I got very close, (got it working at the struct level) but haven't been able to quite get the inference working for coproducts yet 😢

[lloydmeta]

Awesome stuff ! Thanks for the contribution @Diggsey!