Make most 'swh db xxx' commands support reading the db cnx string from anywhere in the config file

Allow db commands (create, init-admin, init, version, upgrade) get the
db connection string from anywhere in the config file.
For example, it can be used like:

$ cat conf.yml
storage:
  cls: pipeline
  steps:
    - cls: masking
      masking_db: postgresql:///?service=swh-masking-proxy
    - cls: buffer
    - cls: postgresql
      db: postgresql://user:passwd@pghost:5433/swh-storage
      objstorage:
        cls: memory

$ swh db -C conf.yml init storage:steps:0:masking_db

This de facto deprecates the usage of the --module-config-key option.

Also add a -a/--all option to these commands allowing to execute the given
command to all matching configuration entries in the config file; this
should help deployment in testing environments like docker.

For example:

  $ swh db version -a storage

  module: storage.proxies.masking
  current code version: 194
  version: 194

  module: storage
  flavor: default
  current code version: 193
  version: 193

This change also make the module name stored in the dbmodule table an
fully qualified module instead of shortened version, i.e. it will now
store 'swh.storage.postgresql.storage' instead of just 'storage',
so there is less "implicit logic" (like removing "swh.", etc.)
when filling/using this piece of information.

We add a bw compat support in get_sql_for_package to ease the transition
until the dbmodule tables are updated. This bw compat logic will
look for the 'sql/' directory not only in the package directly for the
module, but also in parent directories. This allows to keep the code
compatible with current version of swh.storage (in which the sql/
directory and the actual backend submodule do not match).

Doing this, we also stop defining a hardwritten dbname ('softwareheritage-dev')
as default value for the '--dbname' option in 'swh db create' command.

Warning: for the 'create' and 'init-admin' db commands, looking for the
connection string in the config file is mainly useful for test environments
in which the user used to access the backend database have superuser
permissions on the database. In production-like environments, you most
certainly will prefer using an explicit --dbname argument with a
connection with enough permission to handle the job.