std.Target: Introduce Cpu convenience functions for feature tests

[alexrp]

Before:

• std.Target.arm.featureSetHas(target.cpu.features, .has_v7)
• std.Target.x86.featureSetHasAny(target.cpu.features, .{ .sse, .avx, .cmov })
• std.Target.wasm.featureSetHasAll(target.cpu.features, .{ .atomics, .bulk_memory })

After:

• target.cpu.has(.arm, .has_v7)
• target.cpu.hasAny(.x86, &.{ .sse, .avx, .cmov })
• target.cpu.hasAll(.wasm, &.{ .atomics, .bulk_memory })

This is not necessarily the final shape I'd like this API to have; just putting this option up for discussion.

[alexrp]

I'm a bit torn between the current behavior here and assert(family == cpu.arch.family()). I like that the current behavior lets you check the family and feature(s) at the same time, but I can also see an argument that asserting might help catch bugs. 🤔

[alichraghi]

A quick grep shows a bunch of if (is_xyz_cpu) std.Target.xyz.featureSetHas() instances and honestly, I can't imagine a scenario where asserting could be helpful to catch a bug.

[tensorush]

Admittedly, this will sound a bit off-topic, but there's a trivial stylistic nitpick that I have in regards to std/Target.zig, namely, is... functions for determining arch aren't all correctly camelCased:

• isBSD -> isBsd
• isAARCH64 -> isAarch64
• isRISCV -> isRiscV
• isMIPS -> isMips
• isMIPS32 -> isMips32
• isMIPS64 -> isMips64
• isPowerPC -> isPowerPc
• isPowerPC32 -> isPowerPc32
• isPowerPC64 -> isPowerPc64
• isSPARC -> isSparc

There's also isMinGW, which I'd change to isMinGwLibC to match other abi-checking functions.

Although, I guess these're all breaking changes, technically.
Anyway, sorry if I'm polluting the discussion with an unrelated change.

[alexrp]

The problem with those, in my view, is that it's a case where Zig's style clashes with good taste. For example, because we write it as powerpc, riscv, and spirv in snake_case, it should actually be isPowerpc, isRiscv, and isSpirv. I personally really don't like that. isAarch64 is also ugly IMO.

I'm hoping we can just neatly side-step most of this problem with #20690 and #23530.