fetch: Fix various issues related to zig fetch --save

[castholm]

Closes #18639
Closes #21690

• zig fetch --save file/path is now an error.
• --saveing over an existing path entry will now correctly replace it with an url entry.
• Fetching by file URL (as in zig fetch file:///C:/foo/bar.zip) did not previously work, but does now.

The purpose of zig fetch is to copy a package to the global cache to avoid needing to access the network. It is not to manage your build.zig.zon. --save is provided as a convenience since calculating the hash by hand would be unreasonable, but it does not make sense to --save a package fetched by a (CWD-relative) file path since path entries in a build.zig.zon are for relative paths inside a package. path entries can only be added by manually editing your build.zig.zon.

Both zig fetch and build.zig.zon support fetching by file URL scheme, for example if a package is on an intranet network drive, but this did not previously always work due to a field being uninitialized and due to file URL-encoded absolute paths on Windows containing drive letters requiring extra attention. This PR fixes those bugs and improves validation to ensure file URLs are spec-compliant (based on RFC 8089 and https://url.spec.whatwg.org/).

I've verified the correctness of these changes by running the following commands locally (on Windows):

• zig fetch --save ..\..\foo\ -> error (can't save when fetching by file path)
• zig fetch --save ..\..\foo.zip -> error (can't save when fetching by file path)
• zig fetch --save file:///foo.zip -> ok
• zig fetch --save file:/foo.zip -> ok
• zig fetch --save file:///C:/foo.zip -> ok
• zig fetch --save file:/C:/foo.zip -> ok
• zig fetch --save file://localhost/C:/foo.zip -> ok
• zig fetch --save file:foo.zip -> error (invalid file URL)

Additionally, it turns out that there were a lot of test declarations in /src that were unreferenced and untested, some of which were for the package manager internals. I de-bitrotted those tests and added them under a new test-cli-internals test set, which tests everything referenced by /src/main.zig.

[castholm]

I just want to note that this does mean that if the user invokes a command like zig fetch --save ./foo.tar.gz, the package will first be copied to the global cache before printing the error. This is obviously not perfect; ideally, the command should detect that the user passed a file path in combination with --save and exit before doing any work. However, if we want a maximally consistent and correct behavior, each solution comes with its own downsides

• Currently, we test if the path_or_url input is a directory we can open, then a file we can open, then finally a URL. Moving this logic to the cmdFetch() function before we actually fetch the package would mean we now have open file handles that we need to pass to the run() function and correctly close them if any errors occur on the way there (but not if run() returns an error since run() claims ownership of the handle). This is not trivial and will result in ugly code.
• We could change the order of operations and instead try parsing the input as an URL first. However, an input like c:foo (on Windows) or http:foo (on POSIX) would be interpreted as a URL despite possibly being a valid file path, so this isn't ideal. Even if we try to rule out values we know are not valid URLs that can be fetched, an input like http://example.com/example.tar.gz could be a valid file path to the subpath example.com/example.tar.gz inside the directory http:.
• We could also change the fetch command so that the user explicitly has to specify whether the input is a path or url, as in zig fetch --path http:foo --save.

I've thought about this a lot and I'm sure what the best way to handle this is, or if it's even worth putting energy into. I just think edge cases matter, however obscure they might be.

[castholm]

These were unreferenced.