…for erasing

With that it becomes useful for deleting password files and such.

Support some aliases Debian added, and drop some options that Debian
dropped from our list of unsupported options.

This is useful when the key file is acquired dynamically in some form
and should be erased after use.

Note that this code tries to be robust, and removes the key file both on
success and on failure.

…ath logic

Let's do some rearrangements, so that we can later on use this to
automatically search for a key file.

Let's make loading of keys a bit more automatic and define a common
place where key files can be placed. Specifically, whenever a volume of
name "foo" is attempted, search for a key file in
/etc/cryptsetup-keys.d/foo.key and /run/cryptsetup-keys.d/foo.key,
unless a key file is declared explicitly.

With this scheme we have a simple discovery in place that should make it
more straightfoward wher to place keys, and requires no explicit
configuration to be used.

Only then we'll try again to ask the user for a password.

Fixes: #12152

… file system

This adds a new switch try-empty-password. If set and none of PKCS#11 or
key files work, it is attempted to unlock the volume with an empty
password, before the user is asked for a password.

Usecase: an installer generates an OS image on one system, which is the
booted up for the first time in a possibly different system. The image
is encrypted using a random volume key, but an empty password. A tool
that runs on first boot then queries the user for a password to set or
enrols the volume in the TPM, removing the empty password. (Of course, in
such a scenario it is important to never reuse the installer image on
multiple systems as they all will have the same volume key, but that's a
different question.)