Optimize render tree building via RenderTreeFrameArrayBuilder

[SteveSandersonMS]

Implementation of #24464

I'm seeing a 20% improvement for wall clock times on the FastGrid benchmark with this. The gain comes down to (1) making RenderTreeFrame mutable so we no longer have to copy frames every time we close elements/regions/components etc., and (2) creating a specialised variant of ArrayBuilder that knows how to append instances of that struct without going through the factory methods that have to copy on assignment.

We could now also remove all the With... methods on RenderTreeFrame, plus technically all its static factory methods and probably all its constructors too. They are all internal/private. However that would cause quite a bit of noise across our test code, so I don't want to make this PR that much bigger, or make the tests more laborious to write. We can always clean these away any time in the future if we want.

[SteveSandersonMS]

In the end I decided I was uncomfortable with exposing the new mutability of RenderTreeFrame publicly, so what I've done is convert all the newly-writable fields to internal with the suffix Field on their name, plus for each added a corresponding public readonly property that will read its value. The reason for exposing the underlying backing fields via internal (and not having internal set on the accessor properties) is to avoid introducing extra overhead given that this is central to the most perf-critical paths on WebAssembly.

This is technically a binary-breaking change because what was a field before is now a property, but it's not a breaking change for anyone recompiling their code (you can still read the same set of values with the same names). Plus the whole RenderTreeFrame type is pubternal-ish - there's an analyzer warning people not to use it directly, even though some people do. Since this won't affect anyone who recompiles their code, I don't think this is problematic.

[javiercn]

Is the goal that we don't "break" the entire world with this change?

[SteveSandersonMS]

Yes, this change won't be breaking for any code that either (a) is recompiled after this change goes in, or (b) doesn't use RenderTreeFrame directly (like our analyzer tells people).

[javiercn]

I'm thinking of things like bUnit and so on, they'll likely ignore your warning :)

[SteveSandersonMS]

Yes I strongly expect so. I was going to contact @egil about this directly.

[javiercn]

Changes are pretty mechanic.

Looks great! I don't have major concerns since most of the API is internal.

If you want to remove methods in the future, file a follow-up issue so that we don't loose track of it.

[SteveSandersonMS]

If you want to remove methods in the future, file a follow-up issue so that we don't loose track of it.

I'm not saying I definitely do want to remove them. They aren't harmful, and being internal/private, they aren't a liability. I'll leave it to future-us to make this determination.