remove either `std.builtin.Version` or `std.SemanticVersion`

[noiryuh]

Probably because std.SemanticVersion is the rewritten version of std.builtin.Version. But for now, we have 2 structs served for the same purpose (e.g. in build.zig and more)

const zig_version = std.builtin.Version{ .major = 0, .minor = 10, .patch = 0 };
const stack_size = 32 * 1024 * 1024;

pub fn build() !void {
    // ....
    const semver = try std.SemanticVersion.parse(version); // 'version' here is '-Dversion-string'
}

Maybe we can migrate to std.SemanticVersion and deprecate std.builtin.Version to avoid confusing and de-duplicate code.

So while working on this in #13998 I noticed there's this problem: Semantic Versioning 2.0.0 does not accept versions such as "1.0" or "5"; the version always has to include major, minor, and patch.

Here are some places where this is a problem:

• zig/lib/std/zig/system/darwin/macos.zig

  Lines 391 to 393 in 266e2e9

  	const ver0 = try parseSystemVersion(case[0]);
  	const ver1: std.builtin.Version = case[1];
  	try testVersionEquality(ver1, ver0);

  (example: "14.3")

• zig/lib/std/zig/CrossTarget.zig

  Lines 720 to 725 in 266e2e9

  	const max_ver = SemVer.parse(max_text) catch |err| switch (err) {
  	error.Overflow => return error.InvalidOperatingSystemVersion,
  	error.InvalidCharacter => return error.InvalidOperatingSystemVersion,
  	error.InvalidVersion => return error.InvalidOperatingSystemVersion,
  	};
  	result.os_version_max = .{ .semver = max_ver };

  (example: "3.10" in "linux.3.10...4.4.1")

I'm going to suspend work on that PR until there's a clear consensus on what to do because std.SemanticVersion alone can not replace all version needs. Do we have some other more flexible version parsing function in std.fmt maybe? Do we just reimplement version parsing for every case? Etc.

[nektro]

3.10 should set .patch to 0

That's not what I was asking about but I will probably pick it up later again though and just reimplement version parsing on a per-case basis where Semantic Versioning doesn't exactly apply.

Reopened #13998. Maybe I came up with something somewhat satisfactory. @nektro indeed, in the cases I encountered so far it's really just about the patch component that is sometimes omitted in input and sometimes has to be omitted (if zero) on output.
I did a lot of local testing so I'm reasonably confident that at least the std tests might pass in that PR.