Enable relaxing of UnionEncoder requireRecordFields

[dharmaturtle]

I only did Newtonsoft.Json so far because System.Text.Json is proving annoying. I'll elaborate further if you like what's here.

Ref: https://github.com/jet/FsCodec/issues/61

[bartelink]

because System.Text.Json is proving annoying

I know that feeling (and many around the world do!) 😄 see #59

[bartelink]

Thank you for the work thus far - this is looking very promising. Re #61, I had not done much thinking through / imagining of how this might look overall as your implementation is making me do now.

I covered some of these tradeoffs more in the code review comments; there may be things I've yet to consider which will prove some of the following wrong/unworkable, but my thoughts are:

• I had thought that in principle each store should implement it's own checker - you've shown it can live here, and I like it
• I still think I don't want to stuff things into the FsCodec core module but I may ultimately be wrong - someone that wants to write their own mapping functions and/or use a different serializer, they get to define (and maintain) their own rules. Putting helper modules in there also gives a false impression that FsCodec is a massively complex library; the intent is really to define a very minimal set of contracts indeed at that level.
• considering how a contract style checker might be organized can be a useful tool for thinking about where stuff should live; expanding below on that concept

There are multiple axes of constraints:

• store-imposed: Equinox.Cosmos can only store JSON - i.e. embedded byte[] content needs to be base64 encoded
• e.g. DynamoDb might impose slightly different constraints than Cosmos
• more arbitrary: Propulsion.Kafka is looking to roundtrip a representation of an event from a store over Kafka, which in general is fine if its UTF8
• self-imposed: if usin using Equinox.EventStore, any byte[] is fine but we want to have all bodies be valid JSON so we can do JS projections
• style: our team is using F# and we have decided our rule is we use records no matter what for reasons discussed in #61 not all roundtrips may be implemented in all libraries - i.e. some thorny thing might work in FsCodec.SystemTextJson but not in FsCodec.NewtonsoftJson
• We want to define sets of rules that our IUnionContract types should observe as described in #50 (One could imagine building a Roslyn analyzer checking the rules on the fly too)