* Anything which has an explicit "If writing, set up element" rather than merely
serialising directly.
* Also e.g. for ResourceIds, when structurising grabbing the ID of an object
will get the live ID, so we need to get the original ID.
* After simplification memory that's only used for tiled resources would have a
single interval with finish() == UINT64_MAX, which failed the iteration check.
* If a bitfield is precisely equal to one known value, return a literal for it.
Similarly for 0, for both bitfields and regular enums. This helps reduce the
number of heap allocated strings generated while serialising.
* Users should stringify the actual value themselves if so desired. This reduces
the number of string allocations in the structured data since ResourceIds are
common.
* This is a string type which heavily optimises for immutability and minimal
storage. It only contains one pointer to the string data and always
reallocates on modify. For compile-time literals it doesn't modify or
allocate.
* On x64 we use the top bit in a tagged pointer to store a flag of whether it's
heap or literal, on other platforms it uses a separate field (meaning another
pointer sized value effectively, including padding).
* This is best for structured data which tends to use a lot of immutable strings
for type/name information, and only a few for actual string data (which are
only allocated once and aren't modified after that). Similarly we rarely want
to know only the size of any of these strings, we want the whole string so not
explicitly storing the size is not a big deal.
* Overall this reduces SDObject from 128 bytes to 80 bytes.
* For certain very large arrays it can be nice to defer generation of structured
data until it's needed, since often maybe only a handful of elements may be
needed (or commonly none at all).
* Normally the function creates its output to enforce storage (for texture
views) but repeated calls would break that, so we only create when the output
texture ID is 0.
* If chunks come from an allocator they can't be safely deleted because the
allocator may have been reset and recorded over where these chunks were with
other data. Fortunately we don't need to do anything to delete them, so
storing the allocator status up front is sufficient.
baldurk