this does a lot of things, most of which are maintenance:
 - sources update
 - adjust newly-renamed options
 - swap some packages that were removed / renamed
 - update nomsring to newer default ghc
 - remove the deprecated lib.mdDoc from modules/*.nix
 - disable the nixpkgs mollysocket module so my own keeps evaluating
 - bundle the package definition of hikari & wlroots 0.15, which nixpkgs
   has removed as unmaintained (in fairness, they are unmaintained)

this is, in the widest possible sense, a revert of
e88fed18f499a3e8ac98c772bbb62f00d1f8d1d7, which was now a little over
two years ago.

Of course, lots of things have changed since then:
 - this uses npins instead of niv, which is both simpler and still
   maintained
 - i haven't brought back the old deploy lib; I still use
   deploy-rs (with some modifications) to deploy things
 - if you actually use my stuff downstream, you can now use packages/ &
   tests/ & modules/ as entry points directly, while still having some
   control over inputs
 - (since i also don't believe any downstream users actually exist, i've
   not bothered to have a shim flake.nix so your stuff probably just
   broke. well, it was an experimental feature, anyways)
 - in general there's a lot more of the old-fashioned structure back
   again, with default.nix files in subdirectories that form a
   structure, not like how almost everything was just imported in the
   one big flake.nix file

For people who are interested in also having a non-flake config similar
to this one, it's probably best to take a look at inputs.nix (and also
at npins, of course)

with thanks to networkException, who wrote the initial nix package.

otherwise it just fails to start with an error

this allows setting options via an environment file that is passed to
the systemd units, in addition to the ones set during build time of the
package.

For now this is tailored to SECRET_KEY, but it may be useful for other
settings as well (e.g. EMAIL_HOST_PASSWORD), and I'm not sure if it
takes priority over the build-time settings ...

this should be mostly usable for actual deployments. Only thing that's
really still annoying is having to set the SECRET_KEY via Nix, since
not having set it makes the package fail to build. But it doesn't
actually end up in the derivation, so changing it afterwards should be
fine; I've just not tested that yet.

please no one like, actually use this. unless you volunteer to at least
add a script to run database migrations, since currently these need to
be run by hand …