Refactor config loading and server initialization

As is, LoadConfig() does some things that are not strictly related to
the configuration, such as parsing command line arguments. This has led
to a proliferation of different ways to load the config based on various
needs and also prevents tools that need a config but are not services to
use custom command line arguments.

This commit aims to decouple config loading from everything else and
do nothing but loading the config files.

On a high level, this commit:
- renames server.NewServer() to server.New()
- moves config.Debug and config.Addr into the server package
- moves crypto.InitCrypto() call into server.New()
- moves command line parsing into server.New(), using passed-in values
  rather than os.Args

The only changes required for services would be changing

   cfg := config.LoadConfig(":5100")
   server := server.NewServer("meta.sr.ht", cfg)

to

   cfg := config.LoadConfig()
   server := server.New("meta.sr.ht", ":5100", cfg, os.Args)

All other tools will be switched to just LoadConfig() and, optionally, a
call to crypto.InitCrypto(). I managed to completely remove some global
state (addr) and at least make the rest private, so that users are
forced to use the designated functions.

The config module gained support for custom FS implementation, mainly
for testing.

Remove sourcehut-migrate

It now lives in its own repo [1], so it can be tagged and packaged
independently of core-go.

[1] https://git.sr.ht/~sircmpwn/sourcehut-migrate

Add sourcehut-migrate, a unified DB migration tool

This tool will replace both the old `srht-migrate` as well as all
`<SERVICE>-migrate` tools, but services need to be migrated over to it
one by one. This tool is based on brant [1].

Invocation in both production and development can be as simple as:

    sourcehut-migrate <SERVICE> up

The tool will read a config like a regular service (first in ., then
/etc/sr.ht, etc.). The database connection details are taken from the
config. To facilitate development, the tool will check if a folder
./migrations exists; if it does, migrations will be loaded from there.
If no ./migrations folder was found, it will look for migrations in
`<ASSETS>/migrations/<SERVICE>`, where <ASSETS> is also taken from the
config, with a default of `/usr/share/sourcehut`.

For an explanation of the available commands, see brant [1].

This tool also supports a simple command to initialize a newly created
database to the current version (much like the `<SERVICE>-initdb` tools
used to):

    sourcehut-migrate <SERVICE> stamp head

will automatically set the database version to whatever the latest
available migration version is.

[1]: https://git.sr.ht/~bitfehler/brant

go fmt

auth: s/OAuth2Token/BearerToken/g

This also makes some tweaks to the organization of the crypto module to
make it easier for us to add more keys in the future, which will be
necessary for the internal token redesign.

Add debugging command to decode OAuth tokens