Proposal: Comptime allocator builtins

Inspired by #1291.

The current mechanism to obtain persistent mutable state at comptime is closure. I hate comptime closure with a passion that burns with the strength of a thousand white suns. Not only does it violate language principles, it's inefficient for applications that do heavy computations at comptime (regex, interfaces, perfect hash etc.). I sincerely hope #5718 will make it die. In that case, though, we'll need a new way to get mutable state, that doesn't rely on system memory or syscalls at a program level. (Moot with #7396, but maybe there's still some value here.)

I propose two new builtins: @alloc(T: type, len: usize) *[len]T and @resize(buf: *[_]anytype) void. These can only be run at comptime, and produce comptime values. They work as if invoked from a single, global, comptime allocator. One could then implement an analogue of std.heap.page_allocator on top of these, and we're off to the races.

Musings:

• I initially thought of copying the standard allocator interface, however this would have required a choice of either the allocator itself or the allocation functions as the primitive, as well as a lot of implementational complexity either way. Also considered was a monomorphic whole page allocator, but this would have been inefficient and difficult for the compiler to manage. (I am now a wiser woman, and feel that Zig rules, POSIX drools.)
• Acquisition cannot fail in a program-visible way -- a failure to allocate is simply a compile error. I don't see a use case for continuing compilation if the system doesn't have memory for it.
• The global memory quota, being not necessarily equal to the data used and easy to abuse sneakily, should be set outside the program with a command line option; say Dmem-quota=3M or something similar. By default it's something small but not useless, say a few kilobytes.
• This creates pointers to comptime data, potentially where runtime code can see it. For safety, we should either null these pointers in codegen or detect erroneous use at comptime (Compiler intelligence: Pointers to comptime data should not be accessible at runtime #5874). (make closure over comptime var a compile error; comptime vars become immutable when they go out of scope #7396 saves the day again.)
• This presents a use case for comptime defer and comptime errdefer, for code that runs on exit from analysis. I feel we should add this, if we go the comptime allocator route.

#5895 encompasses this. Closing.

#7396 being accepted, the components of #5895 are now cohesive on their own, and can be split out.

I know I reopened this, but honestly, it's an awful idea. At comptime you can just declare whatever data you want. If you need an allocator for something that works with the allocator interface, just declare an array and make an FBA. You can always choose the scope that needs the data, since comptime is deterministic. God damn Zig is awesome.