std.Build.Module should include APIs from CompileStep

[hryx]

Currently it is not possible for an upstream package foo to add C header include paths to a Module it has defined — it's only possible to do this on CompileSteps. The effect of this is that if the package defines a module using @cImport(), a depending project bar that uses this module will fail to build because the headers aren't in its search path.

For now, the workaround in the dependee's build.zig is to call exe.addIncludePath(X) where X is the path to the globally cached package, e.g. ~/.cache/zig/p/hash-of-package/include.

It should be possible for bar to depend on foo without adding this include path. If bar does not call @cImport() directly itself, it should also not have to call exe.addIncludePath at all.

The suggested approach in today's meeting was to expand the API of Module to have (some of? *) the same APIs as CompileStep. This would allow the upstream foo to call mod.installHeadersDirectory() in build.zig, and then bar can use the foo module and find its headers.

*Note: I'm not sure which APIs should be copied from CompileStep. All of them? Just ones related to installing headers?

[hryx]

I played around with installHeader() and friends today and understand them better now, but just wanted to confirm a detail. If I understand, installHeader() doesn't implicitly add the destination as an include path: https://github.com/andrewrk/libmp3lame/blob/50a868a/build.zig#L124 (which makes sense because installation obviously happens after compilation)

If that's correct, then I believe a Module.addIncludePath() would be useful too. Upstream foo can do this, and then depending project bar would not have to addIncludePath(), as it just wants to use foo's Zig module and doesn't do any @cInclude()s itself. That would solve the original problem I ran into.

[andrewrk]

Please note my review comments here: #14731 (review)