bin(run), tests: use the x86_64 backend

[ee7]

This significantly speeds up the testing of a user's solution. In the future, zig will begin to use its native backends by default.

However, as of Zig 0.11.0, the x86_64 backend is still considered experimental:

Although the x86 backend is still considered experimental, it is now passing 1474/1679 (88%) of the behavior tests, compared to the LLVM Backend.

See also the accepted proposal ziglang/zig#16270.

Refs: #63

---

Let's hold off on this for now. But there may be a time when the x86_64 backend is either:

• considered stable enough for the typically simple code that Exercism compiles
• or considered stable in the master branch of Zig
• or considered stable in a Zig release, but is not yet the default

in which case we can merge this PR so Exercism uses the x86_64 backend, without waiting for it to become the default in a Zig release.

Note that this PR currently means that test failure messages (but not error messages) no longer include line and column number information.

[ee7]

The release notes for today's Zig 0.12.0 say about the x86 backend:

The x86 backend is now passing 1765/1828 (97%) of the behavior test suite, compared to the LLVM backend. It is far enough along that it is sometimes useful while developing, mainly due to the fact that it offers dramatically faster compilation speed:

Remaining tasks until it can be selected by default instead of LLVM for debug builds:

• 100% behavior tests passing
• Improved debug info
• Improved runtime performance

97% is quite high, but I guess Exercism should continue to stick with the LLVM backend for now.

[ee7]

From the Roadmap in today's Zig 0.13.0 release notes:

The major theme of the 0.14.0 release cycle will be compilation speed.

Some upcoming milestones we will be working towards in the 0.14.0 release cycle:

• Making the x86 Backend the default backend for debug mode.
• Linker support for COFF. Eliminate dependency on LLD.
• Enabling incremental compilation for fast rebuilds.
• Introduce Concurrency to semantic analysis to further increase compilation speed.

The idea here is that prioritizing faster compilation will increase development velocity on the Compiler itself, leading to more bugs fixed and features completed in the following release cycles.

It also could potentially lead to language changes that unblock fast compilation.