std: replace mem.Allocator.dupeZ and mem.orderZ with *Sentinel versions

[IOKG04]

Similarly to what #25260 did with fmt.bufPrintZ, I replaced mem.Allocator.dupeZ and mem.orderZ with more generic Sentinel versions, so they can be re-used more.

Since most of the *Z functions are there to interact with the operating system/c code (ex. posix.mkdirZ), I didn't change those.

One I did consider changing was mem.joinZ, though in my opinion it'd be worth completely reworking it (and mem.join), so it doesn't only work on []u8s, but on any slice type.
I can do that in this PR too, though some help for naming would be appreciated, cause the join functions as they exist currently should be kept and just marked deprecated, but the new, generic functions should also have fitting names.

closes #25285
also fixes one of the issues described in #22618

[neoto]

I agree that having more flexibility is a good thing, but I disagree with deprecating the *Z methods simply because null-terminated arrays are overwhelmingly more common compared to anything else. Forcing everyone to adapt their usages feels like prioritizing some kind of theoretical flexibility over well-established usability.

[IOKG04]

I too would say that 0-terminated arrays/slices are way more common than all others combined, but as the zen says:

Only one obvious way to do things.

[rohlem]

as the zen says:

Only one obvious way to do things.

Just my 2c, maintainers have to decide, but so far I've seen "one obvious way" to mean "one easily-decidable way", not "only one way at all".
So if you know you're dealing with 0-termination, the -Z functions (which may just call the -Sentinel functions) are the obvious choice,
otherwise you call the -Sentinel functions.
There's always an obvious answer, so it doesn't violate the zen imo.

As another example, std.mem contains both indexOf for searching the entire input and indexOfPos for starting from a certain position.
If we wanted only one way, all indexOf(T, a, b) should be replaced by indexOfPos(T, a, 0, b) (and we could drop -Pos from the name).
But if a call site always starts at 0, the one obvious way is to use indexOf instead of hardcoding the 0. So having both still fits the zen imo.

[GrayHatter]

The advice I was given was that The Zig Zen is descriptive, not prescriptive.

Thus, you should avoid arguments that cite or reference it. Code should stand on it's own merits and it's own arguments, if the only rational or reason for a change is "it feels more like the zig zen to me" it really has no compelling reasons at all.

In this case, while I would have preferred fnNameZ (still taking an explicit Sentinel arg) over fnNameSentinel for all of the above, (shorter names are often better, (especially when you're dyslexic, (sentinel is not a kind word to me))), but a unified style is much more important; and there's a few existing diffs that have already adopted the Sentinel postfix. It would be really nice not to have to remember if I'm supposed to type Z, or Sentinel for each specific namespace.

[alexrp]

https://codeberg.org/ziglang/zig/pulls/30019