Adds non allocating alternatives to ZON parse functions

[MasonRemaley]

Adds the following functions to std.zon.parse:

• fromSliceFlat
• fromZoirFlat
• fromZoirNodeFlat

These are identical to the existing functions with "flat" stripped from the name, but they assert at compile time that the result type doesn't contain a pointer and therefore doesn't need to be freed. As such, the latter two functions do not require an allocator as an argument. (fromSlice still does as it needs to allocate the Ast and Zoir.)

I'm open to alternative suggestions for the names. I think "flat" as in "flat in memory" is pretty reasonable, though it could be misinterpreted as to do with nesting. I would have simply named them noAlloc, but this is confusing since fromSliceFlat does in fact create (temporary) allocations.

Replaces #22835, CC @NicoElbers (thanks for the reminder that I wanted to do this!)

[Trevor-Strong]

Why not just change the only functions to have an Alloc suffix and give these new functions the old names?

• fromSlice -> fromSliceAlloc
• fromZoir -> fromZoirAlloc
• fromZoirNode -> fromZoirNodeAlloc

and

• fromSliceFlat -> fromSlice
• fromZoirFlat -> fromZoir
• fromZoirNodeFlat -> fromZoirNode

Aside from fromSlice, the have different signatures so users will see a breakage and this API hasn't been included in a tagged release yet, so now is one of the better times to make a change like this. Also, this might be the only API in the standard library to have the "default" function be allocating. Everything else I can think of uses the Alloc suffix to distinguish between the two variants. Using a different convention could be very confusing to people learning this API later on, especially without the context of it's introduction not having the no-allocator functions.

I haven't even made a PR to zig yet, so feel free to disregard if this doesn't make sense to you.

[MasonRemaley]

Why not just change the only functions to have an Alloc suffix and give these new functions the old names? [...]

That's a good suggestion, I like that it's consistent w/ the rest of the standard library and that the "default" is non allocating as you mentioned.

Right now it's a little weird because all of these functions technically allocate since they all allocate an AST.

I'm considering writing a parser that doesn't generate an intermediate AST, if I do that then the suggested naming scheme will become unambiguous and since removing the allocator arg is already a breaking change anyway so I could rename them at that point. Alternatively, I could adopt these names now in anticipation of that, but it'd be a bit weird in the interim/if plans change.

(If I do write a parser that skips the AST, I'll make sure the use case in #22973 is still supported.)

[mlugg]

@MasonRemaley I think the naming suggestion above is a good one -- at least, better than what this PR currently does (not your fault; as always, naming is a hard problem!). Mind making that change? I'll probably be happy to merge this then.

[MasonRemaley]

Done!

[alexrp]

Should be mergeable after a rebase to resolve the conflict, I think?

[MasonRemaley]

Whoops, I totally forgot this wasn't merged. I'll go ahead and do the rebase in a minute.

[MasonRemaley]

Rebased but I still wanna tidy up the tests a bit.

[MasonRemaley]

Done, should be ready to merge once CI passes!