make entity startup async and event-driven

[azahnen]

Currently entities (and building blocks) expect all external dependencies (e.g. other entities or databases or resources) to be available on startup. To ensure that, startup runs synchronously in a single thread, with only one entity at a time and entities ordered by type (codelists < providers < services). The onStartup method is then used to run all kinds of initialization, for example spatial extent computation.

Building on #879, this will replace this rigid system with a more flexible and resilient approach. Any initialization that requires external dependencies would no longer happen on startup. Instead, the dependent initialization would be triggered by a state change of the dependency.

That means startup itself will be a lot faster, but entities and building blocks will at first be in their most basic, possibly non-functional state. Most initialization would then happen asynchronously, when the dependencies arrive, which also means it could run in parallel.

There might be an option to mimic the old behavior.

Example

Before

If the required PostgreSQL database is not available, a feature provider will not start. If the feature provider is not available, a related service will not start.
If the database becomes available, the feature provider and service remain stopped. A manual restart of the application is needed to reach the desired state of a running service.
If the database vanishes again after successful startup, the feature provider and service remain started. Instead of communicating this restriction to consumers/clients, they will throw exceptions on related operations.

After

Despite the PostgreSQL database not being available, both the feature provider and the service start. Of course the service respectively some of its building blocks will be in a restricted state and communicate this state appropriately to consumers/clients, see #879.
The feature provider will check periodically for database availability. When it arrives, the provider will run any dependent initialization and change its state to healthy. The service, which has subscribed to state changes of the provider, will also run any related initialization and change its state to healthy.
If the database vanishes again, the provider will change its state to e.g. defective, which will again trigger the service and/or the building blocks to go back to the basic state.

[cportele]

The work on this issue should also address two open issues from PR #705 (Search), since this issue will require a complete overhaul of the schema generation and caching anyways:

• To be able to document the stored queries in the OpenAPI definition, a capability is needed to update API definition one a stored query is updated at runtime. This is not an issue, if queries are provided as part of the configuration.
• There is a general issue with setting JSON Schemas for classes. In general, the right place should be onStartup(), but this method is only executed after the API definition has been compiled.

Also related #814.