module_load() already handles the case of a relative module name;
it is, after all, what is passed to MODULE_TRY_REQUEST_DEPENDENCY
and MODULE_TRY_REQUEST_SYMBOL. In that case, it prepends the
module installation prefix and "modules/" to the path given,
emitting a "translated x to y" debug-level message in the process
which describes the corresponding absolute path it chose to use.

However, the configuration parser for loadmodule lines was
duplicating some of this logic; prepending the module installation
prefix (only). This means that all loadmodule lines would have to
be prefixed with "modules/" since the loadmodule parser was not
doing that. It also means that when loading modules as a result of
encountering a loadmodule line, there is no translation performed
and no corresponding debug message, as opposed to encountering a
module dependency. This makes it harder to follow what's going on.
It also looks slightly uglier, because the "loading" line is using
an absolute path in this case, cluttering the debug output.

Because module_load() is already doing some of this logic for us,
just pass the raw name to it. This means the configuration file
will have to have loadmodule lines without "modules/" in the path.

This simplifies the code, makes logging nicer, reduces the size of
the example configuration file by more than 4k, enables all of the
lines in the example configuration file to fit within 80 columns,
and enables circular module dependencies to be caught more reliably
and even earlier in some circumstances; it is now only processing
path names, as opposed to having to error out much later, at
comparing the published names from the MAPI header after opening it.

Existing loadmodule lines that contain absolute paths will continue
to work. This also means that absolute paths can be provided on
Windows now; the previous code only tested if it started with "/".

Lines which contain relative paths will need to have the "modules/"
prefix stripped from them. Instructions are provided in NEWS.md.