Deprecate `Uuid#setFactory()`, use dedicated factories for `FieldInterface` and for UUID creation

Problem-space

While working on #324, it became evident that the majority of complexity within this library comes from Uuid#setFactory(), which completely switches the behavior of the (supposedly) @psalm-pure operations, as well as the various Uuid::uuid1() through Uuid::uuid6() methods.

Solution

I suggest deprecating and discouraging usage of Uuid#setFactory() and Uuid#getFactory(), as well as deprecating all setters on UuidFactory itself, so that post-instantiation no internals of it can change.

After that, we can drop all this API for 5.0.0, allowing for major performance and design improvements within the core of the library.

Further scope

• The UuidFactoryInterface also needs to be split up a bit: there is no need for instantiating specific UUID sub-types unless the user relies on them, so I'd suggest having dedicated API for that, and dedicated API for retrieving FieldsInterface.
• The FeatureSet is also extremely bloated: while flexible, it leads to a lot of added complexity for supporting things like GUIDs, while separate independent UuidFactoryInterface concrete implementations would be better for both clarity and runtime performance.
• Aggressive inlining can be applied to factory internals once we have split up all details: could even be interesting to use FFI for such purposes, but that is yet to be verified by benchmarks.