stage1 is now a hybrid of C++ and Zig

[andrewrk]

This modifies the build process of Zig to put all of the source files
into libcompiler.a, except main.cpp and userland.cpp.

Next, the build process links main.cpp, userland.cpp, and libcompiler.a
into zig1. userland.cpp is a shim for functions that will later be
replaced with self-hosted implementations.

Next, the build process uses zig1 to build src-self-hosted/stage1.zig
into libuserland.a, which does not depend on any of the things that
are shimmed in userland.cpp, such as translate-c.

Finally, the build process re-links main.cpp and libcompiler.a, except
with libuserland.a instead of userland.cpp. Now the shims are replaced
with .zig code. This provides all of the Zig standard library to the
stage1 C++ compiler, and enables us to move certain things to userland,
such as translate-c.

As a proof of concept I have made the zig zen command use text defined
in userland. I added zig translate-c-2 which is a work-in-progress
reimplementation of translate-c in userland, which currently calls
std.debug.panic("unimplemented") and you can see the stack trace makes
it all the way back into the C++ main() function (Thanks LemonBoy for
improving that!).

This could potentially let us move other things into userland, such as
hashing algorithms, the entire cache system, .d file parsing, pretty
much anything that libuserland.a itself doesn't need to depend on.

This can also let us have zig fmt in stage1 without the overhead
of child process execution, and without the initial compilation delay
before it gets cached.

See #1964

[Sahnvour]

If I understand correctly, the only purpose of userland.cpp is to be able to link zig1 without having to #ifdef calls to the functions it contains even if there is not real implementation provided. And they should not be called while compiling libuserland. So shouldn't they zig_unreachable() to catch bugs where Zig code would depend on the feature it actually implements?

[andrewrk]

Yes that's a good point 👍

[andrewrk]

@Sahnvour ff3cdbc

Now an internal compiler error looks like this (on linux):