* `tuw_config` is a bit nicer than `zzz_invenio_config_tuw`, and should
  still be the last entry in the list considering the usual naming
  scheme

* previously, our configuration magic was performed as part of the
  `finalize_app` entrypoint
* while this worked well enough for most use cases, some extensions
  would break this model by caching values during their initialization
* especially caching-related extensions like to take eagerly create
  clients with the current configuration items, which are hard to fix
  afterwards
* keeping track of all the instantiated clients just to change their
  connection details when we perform our magic really didn't seem like
  a good approach
* so instead, we now made sure that our extension is loaded first and
  can thus perform its configuration magic before any other extension
  has a chance of caching values
* also, extension loading happens after the configuration loading is
  done (especially the handling of environment variables)

* add functionality to assemble some config items (like the DB
  connection string) from their parts
* this was previously implemented in our `invenio.cfg`, but more flaky
  because it had to deal with parsing and setting environment variables
* also refactor the startup module

* this can be very useful for having a single project that is used for
  both "local" and "containerized" execution, where some configuration
  items should be slightly different for either (e.g. `SEARCH_HOSTS`)
* currently we have this functionality implemented in our `invenio.cfg`
  but there it is a bit awkward due to the fact that environment
  variables have not been translated into `app.config` yet

* this makes sure that our custom translations will be picked up, if we
  ever go for translations

* apparently it was a leftover `before_first_request` handler
* reworked it as `finalize_app` entrypoint
* also, added a check if the app config is already a TUW config to avoid
  unnecessary nesting

* to fix our multi-domain setup with Flask 2.x and 3.0
* see: https://github.com/pallets/flask/pull/5634
* this can be removed once we get Flask 3.1+ in

* create dedicated modules for curations & notifications to separate the
  general notifications infrastructure from the curations-related parts
  (and requests)
* split large modules into smaller logical groups
* split tasks.py into three separate parts: curations, TISS, and general

* to make it more obvious that they are all related to user models
* also, rename the modules to better reflect their content
* also, rename some content (e.g. `CurationForm` to `CurationPreferencesForm`)

* replace the removed `@register_menu` decorator, which was using
  `app.before_first_request` under the hood, with a `finalize_app`
  entrypoint function

* Implements custom TU Wien user identity generator

* use `hatchling` instead of `setuptools` as build tool
* remove `MANIFEST.in` since that's specific to setuptools
* also add `uv.lock` to gitignore