Do not use undefined for the ptr field of Allocator/Random instances

[squeek502]

The use of undefined here meant that it was always unsafe/illegal to compare the ptr fields of Allocator/Random. However, this restriction is not mentioned anywhere and the ptr field is being compared in real code, e.g. std.process.Child.collectOutput, which can lead to undefined behavior in release modes (see #21756).

There are two ways to address this:

1. Codify that comparing ptr is always illegal/unsafe, and remove all existing comparisons.
2. Set ptr to a legal dummy value, similar to the value returned by Allocator.alloc when a zero-length slice is requested.

The first option seems like footgun central (at least until usage of undefined is fully safety-checked in safe modes [#211]), so I went with the second option.

Closes #21756
Closes #17704

[rohlem]

Since this is common to all pointer types, a utility method might make sense - something like std.mem.validUnusedPointer(PointerType)?

[squeek502]

Good idea, added that as std.mem.dummyPointer and used it for the ptr fields and the std.mem.Allocator implementation. From the dummyPointer commit message:

Confirmed that the pointer values returned for 0-length allocations are unchanged. Tested the following:

allocator.alloc(u8, 0);
allocator.alignedAlloc(u8, 256, 0)
allocator.alignedAlloc(u8, 2048, 0)
allocator.create(u0)

and tested realloc with:

const slice = try allocator.alloc(u8, 1);
const realloced = try allocator.realloc(slice, 0);

and

const slice = try allocator.alignedAlloc(u8, 256, 1);
const realloced = try allocator.realloc(slice, 0);

[jibal]

As a general rule, undefined should only be used to save execution time when you know that all code paths will result in the value either being set or never used, and only when it has an actual impact as with initializing large buffers (or smaller buffers in long loops). It should never be used when it is visible externally, as was being done here.

(It might be a good idea to downright disallow undefined pub scalars.)

[rohlem]

@jibal I do think it makes sense to have a global var initialized to undefined and initialize it before the first usage.
For const it's much less useful, but it's still correct if that particular struct field should never be used in code.

I think the main surprise is that assigning an undefined value is valid, and that after a = x; b = x readers may expect that a == b.
The two exceptions to this are NaN (which are specific to floating point types) which yields false,
and current undefined semantics (which currently apply to any type, as we currently have no maybeundefined attribute in the language) which is illegal behavior.
(Not saying this should change, just an observation.)

[jibal]

Why have a pub field that should never be used? These are footguns and totally unnecessary UB. Anyway, I suppose having the compiler ban it is not the Zig way, but IMO library code should not be planting these mines.