Add generator overriding

[Soupstraw]

This PR makes it possible to specify custom CBOR generators for specific rules. This can be useful when it is not possible to specify all of the constraints using CDDL's control operators, but you still want to have the generator generate valid data for your test cases.

[lehins]

Here is some of my feedback. I'll think more about what can we do about the problem that we now store a function in a type that has Show and Eq instances, whcih should never be the case

[lehins]

What's the reason for the downgrade?

This caused a whole bunch of unnecessary diff. Could you please revert it and undo all of the unrelated changes?

[lehins]

Why not just name the actual constructors? I don't see a point in pattern synonyms

Suggested change

	= SingleTerm Term
	| PairTerm Term Term
	| GroupTerm [WrappedTerm]
	= S Term
	-- ^ Single Term
	| P Term Term
	-- ^ Pair Term
	| G [WrappedTerm]
	-- ^ Group Term

[lehins]

Inability to derive Show, Eq and Generic is very error prone and it would be better to avoid if possible. Looking at Hashable instance makes me cry.
Unfortunately, I do not have a suggestion how to avoid it. 😞

[Soupstraw]

It might be possible to replace CBORGenerator with a type parameter in the definition of CTree and then use some dummy type for implementing these instances.

[nc6]

Nicer than this would be to wrap the generator function into a synthetic type that has overridden Eq, Show, Ord instances

[nc6]

In other words, make CBORGenerator a (bad) instance of these things.

[lehins]

In other words, make CBORGenerator a (bad) instance of these things

I did think about that, but that just moves a problem to a different place.

Problem with this approach in general is that you cannot provide a lawful instance for Eq when type contains a function and thus you could easily break referential transparency, which is one of the things we really like Haskell for 😁
It could be argued that it is not a big deal in this case, and it is true, but it does make me cringe looking at it.

[Soupstraw]

I think it would make sense to add some index type to the AST anyways, because that would let us use trees that grow to have a different AST representation for each purpose. For example we don't need generators at all if we only use that AST to pretty-print, so the pretty printing AST could have a unit type in place of the generator. Similarly we can get rid of the comments field if we're using the AST for verification, so the verification logic doesn't need to deal with comments at all.