Confusing implicit order constraints when setting custom handlers

[tm-ms]

When setting a custom type handler and a custom eager storing field evaluator, the order in which both setters implicitely defines if the custom eager evaluator is used at all.
This is unnecessarily confusing and must be fixed.

The reason behind this is:

• Registering a custom type handler requires the custom type handler registry to be created.
• Creating the custom type handler registry includes creating and registering the native type handlers.
• Creating the native type handlers requires the type handler creator to be created.
• Creating the type handler creator requires the eager storing field evaluator.
• If no eager evaluator is set at that point, the default one is created and unchangeably used
• Any replacing in the foundation afterwards will have no effect on the type handler creator.

EmbeddedStorageManager storage = EmbeddedStorage.Foundation()
	.onConnectionFoundation(f ->
	{
		// implicitely crucial order, dangerous
		f.setReferenceFieldMandatoryEvaluator(new CustomEagerStoringFieldEvaluator());
		f.getCustomTypeHandlerRegistry().registerTypeHandler(new CustomBufferedImageHandler());
	})
;

Even adding a layer of indirection (custom eager storing field evaluator provider) would not fix that, since the type handler creator needs the actual field evaluator upon beginning to create type handlers.

Separating custom type handlers and native type handlers into two registries would ruin the possibility to optionally replace a native type handlers with a custom one in case one wants to use one's own type handling logic instead of the default one.

But there is another, pretty simply solution:

On the foundation level, all custom type handlers are collected in a separate,intermediate type handler map without even creating the actual custom type handler registry.
When the actual custom type handler registry is created, then all native handlers are registered (same as now), but then all the custom type handlers from the intermediate custom type handler map are registered, still potentially replacing any default native type handlers.

Adding that map is a trivial change and thus done right away.

The only danger with this is, that there ist still a "getCustomTypeHandlerRegistry()" providing logic getter that will create and return the internal registry and nothing in the API prevents a user from calling that "too early" instead of the unproblematic "customTypeHandlers()" property accessor getter.
This will have to be covered by the method's JavaDoc.

[tm-ms]

Implemented, tested and committed.
Done.