Workaround for exceeding stack limit on iOS devices

[shadowfacts]

Closes #806

The root cause of the on-device crash is that the stack grows by an absurd amount in the ViewTreeBuilder.fromNodes call—so much so that we exceed the 1MB stack limit.

In fromNodes, the stack grows by about 10KB per call to f in the function, regardless of whether the call is actually made. And with 55 call sites, that puts us at ~550KB stack growth and over the limit. I'm not entirely certain, but I suspect that's all coming from type metadata for the massive _ConditionalContent that is the result of BuiltinRegistry.lookup (commenting out most of the switch cases in that method dramatically reduces the stack size).

We can workaround this by moving that giant lookup switch to a separate view type, which effectively splits the stack growth into two separate phases—one for the fromNodes call (~177KB, which is 3.2KB per f call site) and one for BuiltinElement.body which contains the switch (~300KB)—so we don't hit the stack limit anymore.

This fixes the immediate issue, but this is still a lot more stack space I would like to be using. Unfortunately, I'm not sure there's anything more we can reasonably do, since I suspect the actual code that's using the stack excessively is being generated by the compiler.

[bcardarella]

@shadowfacts is this a permanent solution or something to just get unstuck for now? If it is the later I'd prefer that we dig in and find longer term solution.

[shadowfacts]

I think this is somewhere in the middle. It achieves the immediate goal of getting the library work on-device again, but it's a reasonable medium- to long-term solution. The even longer-term solution is likely in the compiler internals (which is beyond my expertise) and we would not be able to get it implemented or rely on it any time soon.