Refactor formio integration

[sergei-maertens]

From #1099, #1059 and #1054 it's clear that we need to re-structure our code to manage (custom) formio types:

• Hooking up special custom types with backend mutations
• Formatting the values of vanilla and custom FormIO components

This ticket describes the technical design to resolve both mentioned issues.

Design principles

• We provide first class support for FormIO
• FormIO (or generally: vendor) specific integration code is contained in its own package (i.e. -> do not intertwine it with vendor-agnostic OF code)
• Pluggable & testable

Tasks

• Create a new top-level package openforms.formio
  • Subpackages custom_types and formatters
• Set up the custom field registry
  • define the register in openforms.formio.custom_types.registry (move from openforms.forms.custom_field_types)
  • Ensure that the register inherits from our base register class to make things consistent
  • Define a custom base type inheriting from openforms.plugins.plugin.AbstractBasePlugin
  • A custom type can have two modes of operation:
    • Return value to append FormIO component schema(s)
    • Mutates given FormIO component schema
  • The handler must process components recursively (i.e.: use FormDefinition.iter_components(...), currently not the case
  • The handler also takes a submission object for context, instead of the request. The information possibly on the request should be persisted on the submission instead (such as authentication state).
  • Split up hooks into part with and without input data ('static' impact + data-dynamic impact)
• Set up the formatters registry in openforms.formio.formatters.registry
  • A formatter takes two arguments: value and component, with component being the FormIO json schema
    • This has a big impact - the extra context of component is now not passed along and will lead to restructing in other places!
  • Define a module with vanilla Formio formatters openforms.formio.formatters.default
  • Define a default fallback formatter (could simply be str(value)), used for (custom) types without explicitly registered formatter, to avoid crashes
• Consider marking formatters (or types?) as presentation only (vs. data) -> WYSYWIG, fieldsets, columns... (part of Labels of components hidden (direct or by logic) show up in summary #1451)