Allow registering function-based entrypoints for mappings

[slint]

Currently we only support registering mappings via Python module "paths" that in turn contain all the mappings in raw JSON, following a certain directory hierarchy to assist with alias definition.

Motivation

This method has surfaced several problems over time:

• Mapping definitions can get very large
  • "Native" composition capabilities for indices/mappings are not great at the moment
    • Index and component templates can be complex to reason about in terms of priorities and what the resulting mapping will be (the only way to find out, is by trying to create an index and see the result)
    • They're mostly focused on logs and monitoring storage use-cases
• Very little reuse of existing logic, which ends in inconsistent definitions for the same type of objects across different indices (e.g. an organization/affiliation object looks different when used in a bibliographic record vs. an authority record, even though they share the same structure and types).
• Difficult to implement "dynamic" mappings
  • Features like Dynamic templates can solve some use-cases, but they're also difficult to manage.
  • Implementing features that rely on config flags isn't possible, since any indexed fields have to be defined in the centrally managed JSON mappings.
• No support for comments in JSON

Proposal

Allowing function-based entrypoints (similar to e.g. to the blueprint_loader) that e.g. return plain Python dictionaries for the mappings, would solve several of the above problems:

• Mappings can be programmatically composed using Python code. That could be achieved
• Configuration variables can be taken into account to include/exclude certain fields