* Invenio-Config already takes care of checking the value in real
  Invenio applications and issues a warning if it's unset

* 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