stage1 caching

[andrewrk]

See #1416

• move builtin.zig to its own cache
• get rid of zig-cache dir
• output files into cwd
• fix zig build not knowing where the output paths will be
• fix tests
• include .h files from translate-c in hash (error message for attempting @cImport and --cache on for now)
• macos os.cpp implementations
• windows os.cpp implementations
• include libc in hash (error message for attempting --library c --cache on for now)
• cache eviction (upon successful stage2 build we will delete the stage1 cache)
• tmp file cleanup

see #1344
closes #881

[andrewrk]

Sadly we can't use hard links to output artifacts, because users could - even though they shouldn't - modify the output files, which would undermine the assumptions of the cache system. I shudder to think of the bug reports I would get if this happened.

I'm thinking that we do one of two things:

1. copy output files from the cache dir to the output path. This has the unfortunate downside that if the compilation is never done again, this was a waste of a file copy. If the artifact is very large, this could be quite expensive, and potentially even if it was a cache hit, could be more expensive than creating the output file in place.
2. make a distinction between different kinds of builds. In practice, the caching system will help when building compiler_rt.a, builtin.a, zig run, and zig build, and usually won't help otherwise. We always know which one we're doing, so it could just be enabled for the high reward ones and disabled otherwise. We'd never need to copy from cache dir to output directory - in all 4 cases above we can use the artifacts directly from the cache dirs. And then normal builds can output artifacts directly to their final output paths (either cwd or the explicitly provided --output-file)

After typing this out, it seems like (2) would be preferable.

[ghost]

does this make the tests run faster or something like that? because in the one issue you liked above it sais

Since this is a large, fairly complicated and only impacts usability/performance of the command, this should only be implemented for the self-hosted compiler.

[andrewrk]

There are several problems causing CI failures right now. One of them is that we hit the limit for how long tests can run. This shaves off about 10% of the time.

Also I got tired of zig build taking a long time when working on self-hosted :)