Let an install work out where it is

[tamnd]

Fixes #329.

An unpacked install could not find its own standard library:

C:\> mojo build hello.mojo
hello.mojo:1:1: error: 'std' is required for all normal mojo compiles.

Nothing had told it where it was. Every path the compiler needs is the package root plus something, and the package root came from modular.cfg or from MODULAR_MOJO_MAX_PACKAGE_ROOT and from nowhere else, so it was empty for an install that no installer and no shell profile had been near. The import path was worse off again, with no default at all, not even a relative one, which is why the standard library was the first thing to go missing.

The directory above the one holding the executable is the answer and the executable already knows where it is. That goes in as the last resort in Config::getPath, after the config file, the environment and the runfiles have all had nothing to say, so nothing that works today is affected. The import path gets lib/mojo under the package root, next to the REPL entry point that was already found the same way.

On Linux and macOS this never came up, because an install arrives through a package manager that writes a config file on the way in. On Windows the normal way to get a program is to unpack a zip, and a zip cannot carry a config file naming a path that nobody knows until the moment it is unpacked.

Verified on a Windows host, with MODULAR_HOME, MODULAR_MOJO_MAX_PACKAGE_ROOT and MODULAR_MOJO_MAX_IMPORT_PATH all unset:

C:\tmp\bld1> mojo build hello.mojo
BUILD_RC=0
C:\tmp\bld1> hello.exe
hello from a windows build
RUN_RC=0
C:\tmp\bld1> mojo run hello.mojo
hello from a windows build
RUN2_RC=0

Linux tier 0 was run with this change to check the fallback stays out of the way where a config file already answers.

The empty argv0 handed to getMainExecutable is deliberate and there is a comment about it. It is used only where there is no better source, which on Linux means /proc is not mounted and on Windows and macOS means never, and an empty string sends that fallback looking along PATH for a program with no name, which fails quietly. A null pointer would be dereferenced there instead.

Part of #319, which is the archive this makes usable.