counters: allow deriving Count for generic types

[hawkw]

Currently, placing the #[derive(Count)] attribute on a generic enum
doesn't compile. This branch changes the #[derive(Count)] code
generation to support generic types. If a type parameter is used as a
field with the #[count(children)] attribute, the generated counters
struct will also be generic over that type parameter, and contain the
counters type for that type's Count implementation, with a where
clause requiring that type to also implement Count. If the type
parameter is not used in a field that has the #[count(children)]
attribute, the generated counters struct needn't be generic over that
type parameter,¹ so we exclude it from the counter's struct list
of type params. This required a bit of a complex change to the code
generation to implement.

I've added a new example of deriving Count for generic types,
including one that's generic over type parameters that don't get used
in a #[count(children)] field. This example compiles, verifying that
we now generate code that makes sense when deriving Count for generic
enums.

Footnotes

1. and, in fact, if the counters struct is generic over a type
   parameter that it doesn't actually use, it won't compile, as the
   type parameter is unused. ↩

[cbiffle]

FWIW I've also run into this.

[hawkw]

Yeah, as far as I understand it, it just needs to be IntoIterator, but it seems like the HashSet's IntoIterator implementation doesn't meet some required bound in quote somewhere...