Restructure the staged build to be simpler

[brson]

I'm finding I strongly want to do this before #4513.

It's hard to explain.

Our build artifacts are divided between 'host' and 'target' artifacts, but all host artifacts start out as target artifacts and are 'promoted' to host artifacts.

The directory structure of our output reflects this:

x86_64-unknown-linux-gnu/
    bin/ - 'host' binaries. This is where the compiler lives. Copied from a target bin directory
    lib/ - 'host' libraries. Libs used by the compiler. Copied from a target lib directory
        rustc/ - The 'target' subdirectory, under which target artifacts (for multiple architectures) are stored
            ${target}/ - There are as many of these as targets the compiler supports
                bin/ - Target binaries
                lib/ - Target libraries

During the build, the compiler puts artifacts into the target directories, then at some point, the target artifacts with the same triple as the host artifacts are promoted to the host directories, but the way we do it is complicated.

Currently the build progresses like so:

• Download stage0 host artifacts
• Use stage0 host compiler to build stage0 target artifacts
• Copy stage0 target artifacts to stage1 host artifacts
• Use stage1 host compiler to build stage1 target artifacts
• etc.

The critical problem here is that artifacts are promoted from stage N to stage N + 1. This results in the final output being the result of builds from two different compilers. It was a poor choice.

What we are instead going to do is

• Download stage0 host artifacts
• Don't do any further work in stage0
• Use the stage0 host compiler to build the stage1 target artifacts
• Copy the stage1 target artifacts to stage1 host artifacts

This should be much simpler to understand and maintain.

[brson]

After getting some of the way through this I don't think this strategy works. It makes the stage1 host compiler not work with the stage1 target libraries since it has to interpret metadata output by the stage0 compiler.

[brson]

OK I haven't given up on this yet. The above is just one of many possible problems with a bootstrapping compiler, and it may be a worthwhile price to pay.

[nikomatsakis]

I am not sure. The fact that we don't have to interact with artifacts produced by an older compiler has been an amazing boon for us. It means we can change our AST without worrying at all about breaking inlining, for example.

[brson]

ok