independently cache @cImports and C object files

[andrewrk]

My changes in #2005 integrated @cImport with the caching system, so that if a header that is indirectly used changes, Zig knows to repeat a compilation. That's for the entire compilation though. @cImport and objects built with --c-source represent an independent compilation that can and should be independently cached. Caching for both features works the same way:

• The compiler id hash uses the existing global cache mechanism
• The project-local zig-cache directory is used to store hashes of the inputs:
  • The global compiler id hash
  • The command line which is given to clang
  • Any file paths which are part of the command line are "file hashed" (the caching system takes into account their contents)
• -MD -MF foo.d args are inserted by zig and used to collect a list of files used when doing the compilation. These are "file hashed".
• The project-local zig-cache directory is also used to store the outputs:
  • in the case of @cImport, the rendered .zig file translated from C. This solves a whole bunch of problems, for example debug info not being able to use a source file due to compiling straight from in-memory translated AST. It also makes it easier to introspect when troubleshooting.
  • in the case of compiling C source into an object, the object file produced by clang.

This makes sense to do in both stage1 and stage2 because although Zig will be doing incremental builds of zig code, compiling C code and importing .h files will always be at this "object" level, and will always make sense to cache this way.

Once implemented, this will make @cImport and objects built with --c-source near-instantaneous on subsequent builds, when none of the relevant C source files have changed.