This gets rid of generators completely from the SSR code in favor of a thunk/trampoline approach where render functions can return thunks that are called to continue rendering. This keeps our ability to render synchronously or asynchronously, while improving perf.

Benchmarks from #5103 are merged into a separate branch https://github.com/lit/lit/tree/ssr-thunks-benchmarks and show an 18x improvement compared to main.

This approach works by mapping a template's opcodes array into an array of strings or thunks and performing all render state access and mutation in those thunks. Consumers must iterate the array and when they get a thunk, they have to call it and process the return value. The return value can be undefined, a string, another render result, or a promise.

The thunk representation converts recursion and generators into a kind of continuation, and this appears to eliminate a huge amount of overhead.

Like the generator approach, synchronous consumers can throw when they encounter Promises, so we can implement renderToString() and continue to render synchronously inside of React.createElement patches, etc.

Asynchronous consumers can pause evaluation simply by not calling the next thunk yet. They must await the promises return by thunks, and can pause when they receive backpressure signals, etc. from downstream consumers.

The change is mostly backwards compatible. render() continues to return RenderResult, which is still an iterable of strings or promises. A new function called renderThunked() is added that returns a ThunkedRenderResult, which is an array of strings of thunks. render()callsrenderThunked()` and wraps the result in an iterable that uses a trampoline to read through the result for a small overhead.

collectResult(), collectResultSync(), and RenderResultReadable have been updated to accept both RenderResults and ThunkedRenderResults. Users who are already using those to consumer renders can just change their render call from render() to renderThunked() to get the best performance. All existing users will get a signification improvement either way though.

Further optimizations are likely possible. One idea is to reduce the number of closures produced by making a Renderer class that keeps the current render state on a stack and produces new values when calling next. Because of this, the ThunkedRenderResult type might not be very stable going forward. We may see a few major versions go by as we settle this down - this is labs after all!

One breaking change here is to the return type of the ElementRenderer methods. They now directly return a ThunkedRenderResult. This may be a good stable API to settle on, since if they return iterables of strings, we have to chain iterables (which we did with yield* previously) or change the return type to support iterables of iterables and make nested iterables responsible for kicking off execution of their render when next() is called - essentially a manual generator.

Custom ElementRenderers are more rare than direct SSR render() users, so it may be worth some churn here to land the drastic performance improvements ASAP, then adjust APIs in future major versions if needed.