Establish proper custom-formio-types architecture

[sergei-maertens]

Currently in the context of #297 we have a custom FormIO component type which is modified on-the-fly in the context of a submission.

This works by taking the FormIO JSON schema component and invoking any registered handlers to the type, and the component can be mutated or a new component returned that replaces the custom type (it's converted to vanilla FormIO components).

The current implementation stems from an old proof of concept worked up during a one-day hackaton, so the architecture needs to be cleared up and set in stone:

Add a new package under openforms.forms.formio_components

We are scoping this under form-design/form definitions.

Set up a custom formio type registry

Using openforms.plugins utilities, we can create a new registry class intended for FormIO types.

We should have a base plugin/type class to encapsulate formio specifics:

class CustomType(BasePlugin):
    pass

Intended python API is:

@register("myCustomType")
class MyCustomType(CustomType):
    def __call__(self, component: Dict[str, JSONValue], submission: Submission) -> Optional[JSONValue]:
        ...  # mutate component or replace it alltogether

Which means a custom formio type "myCustomType" met during configuration processing will invoke the plugin/handler with the component definition (before mutation) and the current submission for context.

Note that there is a layer approach here - the nature of such a custom type may itself again offer options in a plugin-like structure, e.g. fetching data from HaalCentraal BRP or fetching the same data from StUF-BG. This can be done in a variety of ways - project wide configuration, or possibly component-specific options. That can in turn again use a registration system.

[sergei-maertens]

#1068 has the technical implementation details