Add a symlink field to build.zig.zon which supports keep, omit, and copy

[andrewrk]

This is a proposal to address the use case described in #17652.

The idea here is to add a new field to build.zig.zon when fetching a tarball that describes a symlink strategy when unpacking:

    .dependencies = .{
        .libz = .{
            .url = "https://github.com/allyourcodebase/zlib/archive/refs/tags/1.3.1-3.tar.gz",
            .hash = "1220138f4aba0c01e66b68ed9e1e1e74614c06e4743d88bc58af4f1c3dd0aae5fea7",
            .symlink_behavior = .keep,
        },

The enum:

/// Describes how to handle all symlinks when unpacking, before hash computation.
pub const SymlinkBehavior = enum {
    /// (default) create symlinks when unpacking
    keep,
    /// skip creation of all symlinks when unpacking
    omit,
    /// make copies of all files that would be symlinked. Uses hard linking when possible as an optimization.
    copy,
};

[tauoverpi]

Since unpacking strategy depends on the build host, wouldn't this leak build-host specific configuration into zon for all that pull in a package with this as a dependency thus creating copies where there doesn't need to be?

Alternative would be to have copy as a fallback strategy (thus removing this option from zon) instead where a symlink is attempted and copy on failure (likely copy by default based on host where it's known prior such as for windows). This does however still make it possible to have packages extract to a much larger size than within the tarball (maybe there's a usecase for limiting tarball size? but that's another issue).

[andrewrk]

Good point, if package A and package B both depend on package C, but package B uses a different symlink strategy, the hashes will not match, and there will be 2 copies of C.

However that's also the case if someone manually edited a tarball to delete symlinks and uploaded it somewhere else, and it's also the case for packages that have different but compatible versions.

So I think it falls alongside an already important use case that is not solved yet, which is managing duplication in one's dependency tree.