Encapsulate and slightly optimize string contexts

[Ericson2314]

Motivation

These steps are done (originally in order, but I squashed it as the end result is still pretty small, and the churn in the code comments was a bit annoying to keep straight).

1. Create proper struct type for string contexts on the heap

   This will make it easier to change this type in the future.

2. Make Value::StringWithContext iterable

   This make some for loops a lot more terse.

3. Encapsulate Value::StringWithContext::Context::elems

   It turns out the iterators we just exposed are sufficient.

4. Make StringWithContext::Context length-prefixed instead

   Rather than having a null pointer at the end, have a size_t at the beginning. This is the exact same size (note that null pointer is longer than null byte) and thus takes no more space!

Context

Also, see the new TODO on naming. The thing we already so-named is a builder type for string contexts, not the on-heap type. The fromBuilder static method reflects what the names ought to be too.

---

Add 👍 to pull requests you find important.

The Nix maintainer team uses a GitHub project board to schedule and track reviews.

[Radvendii]

I don't really feel in a position to critique style, as I'm still new to contributing to CppNix, but my 2 cents is that this feels like endless layers of abstraction. How often are we planning on changing this type? Does it really need a name?

[Ericson2314]

We could give a shorter / less-qualified name.

I would say we do want to change it with some frequency.

1. Already, there is the change you just did.
2. And after that, I've long wondered whether squashing the string context elems down into these strings instead of having more pointers is good. (For example, we loose some aliasing opportunities with the squashing.) So I could see us trying changing it again on that count.
3. Even if we don't change, we may want to reduce the amount of string context <-> string context builder round trips. So that would involve changing some existing signatures, and it is nice to have readable diffs during that.

[Ericson2314]

OK @xokdvium, it's all yours now!

[Ericson2314]

aww I did think my [/*size*/] was cute :)

(not a serious request to bring it back.)

[xokdvium]

Yeah, I could do a more serious pass documenting our usage of flexible array members in the codebase. I wonder if it's an issue for portability when it comes to MSVC.

[Ericson2314]

look good! (approving @xokdvium's rebase / slight edits)

[xokdvium]

Cleaned up slightly and used placement new. That hacky enumerate could easily be replaced with a std::ranges::transform