move `@cImport` to the build system

[andrewrk]

This issue is to remove the @cImport language builtin, instead relying on the feature being provided by the build system (std.Build.Step.TranslateC).

This removes one dependency on libclang inside the Zig compiler executable, which is required for #16270. In the near-term future, the translate-c implementation will still be inside the Zig compiler executable, along with the ability to compile C/C++ source files. However, we can prepare users for this transition by solving the use case via the build system rather than a language feature.

As a consolation prize, the TranslateC build step can be enhanced with advanced settings, such as namespace stripping and validation of existing bindings. Since changes to this don't require changing the language, it's OK if the scope & complexity increase to some extent.

Blockers:

• translate-c build step causing crash in build system #20648
• move https://ziglang.org/learn/build-system/ to become a guide along with the language reference
• translate-c build step lacks a way to link system libraries #20649

Related:

• C interop: expected type bool found c_int #19950
• translate-c should not emit 'pub' for static functions #2314
• additional tooling for ABI compatibility verification #20654

[mlugg]

A small extra note: this eliminates one quite common use case of usingnamespace in the wild, which is to have a c.zig containing a pub usingnamespace @cImport(...) declaration. Instead, you now use a TranslateC step as described above, and directly expose the generated file to Zig code as a module.

[149-code]

@andrewrk would this mean that in order to interoperate with c, you need to use the zig build system?

I have a small personal project written in c built using make files. Im currently extending it by writing new zig code that cIncludes header files and invoking the zig compiler from make (i.e zig build-obj).

Would this use case not be supported anymore?