std.Build: add support for adding specific global search paths

[BratishkaErik]

This allows more granularity when adding search paths, complementing
--search-prefix for more specific use-cases.

Multi-arch library layout

On systems with multilib support (e.g. Gentoo with 32-bit and 64-bit
libraries in /usr/lib and /usr/lib64 respectively), using
--search-prefix option can cause incorrect library selected.

For example, if I want to link system libcurl library when building
Zig program for non-native or explicit native-compatible target,
I can try using --search-prefix /usr, which will automatically add:

• /usr/bin as search path for binaries (fine),
• /usr/lib as search path for libraries (incorrect),
• /usr/include as search path for includes (fine),

In my case it will find 32-bit libraries for 64-bit target, causing
linker errors:

$ zig build -Dtarget=x86_64-linux-gnu.2.35 --search-prefix /usrerror: ld.lld: /usr/lib/libcurl.so is incompatible with elf_x86_64

New --search-paths option allows to add search paths explicitly,
using passed ZON file as a specification. You can repeat multiple
times to add many different search paths if needed.

.{
.binaries="/usr/bin"
.libraries="/usr/lib64",
.includes="/usr/include",
}

Other layouts (GCC or Android NDK etc.)

Another use-case is when binaries, libraries and includes are
distributed across different hierarchies. Suppose I want to correctly
find gcc binary and link gccjit library for my project:

.{
.binaries="/usr/x86_64-pc-linux-gnu/gcc-bin/14/",
.libraries="/usr/lib/gcc/x86_64-pc-linux-gnu/14",
.includes="/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/",
}

Or use Android NDK:

.{
// you can omit fields or set `null` if you don't want to search them.// .binaries = null,
.libraries="/path_to_ndk/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/aarch64-linux-android/35",
.includes="/path_to_ndk/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include",
}

.{
.libraries="/path_to_ndk/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/aarch64-linux-android",
}

[BratishkaErik]

aarch64-linux-debug failure seems to be a regular error.BrokenPipe, not sure what causes x86_64-windows-release failure, it might be related but then why only 1 test and why debug worked fine

[alexrp]

I like where this is going overall; seems obviously useful to distro maintainers. @andrewrk should probably have a look too though.

[alexrp]

LGTM, but will let Andrew have a look also.

[BratishkaErik]

Maybe LazyPath is not the most suitable choice here? They are used by findProgram in configure phase, and so can't have generated LazyPath.

[alexrp]

This will have to be resubmitted on Codeberg once https://codeberg.org/ziglang/zig/issues/31691 is done. (We currently have a moratorium on std.Build changes due to Andrew's ongoing work in this area.)