Redesign Arbitrary registration

[kurtschelfthout]

See #396

Overview of design:

• Removed mutable Arb.register method
• Introduced IArbMap type which encapsulates an immutable Type -> Arbitrary<'TType> map.
• Made Property of the form IArbMap -> Gen<...>, in other words a "Reader" of the arbmap state. I saw no reason to also make it a "Writer" but that could be easily achieved by also returning an IArbMap.
• Now that the map is immutable I saw an opportunity to remove the Arb.Default API - this unfortunately makes discovering which instances are available harder, then again you could say this was already largely the case (e.g. you could only know that union, record types, enums etc were supported by reading the docs). From a maintenance perspective this is a big advantage though, plus there is now only one way to do things.
• In any case, I expect considerable churn in the Gen and Arb API - with Implement integrated shrinking à la Hedgehog? #403 I'm envisaging that Gen will absorb all of Arb, and that Gen essentially contains only parametrizable generators (and almost all of the current primitive generators will be parametrized, increasing flexibility significantly)
• While working on this I couldn't contain myself and had the idea of making TypeClass (to be renamed at some point) into a sort of parameter-based dependency injection thing. The idea is that in time this allows me to remove a whole bunch of code to put together the default Arbitrary (or Gen by then) instances.

The ArbMap design here is rather final - it seems good to me and fullfills pretty much all requirements set forth in the RFC.

The Arb API changes here are preliminary, as well as other API changes - in particular, I'm expecting that Gen and Arb will be merged.

Finally, I can see how this opens some opportunities to enhance registration functionality in the vein of #334

TODO:

• - update release notes
• make docs work