Feature Request: Support loops with await expressions in event handlers

[EbaraKoji]

Problem

Following up on #349 and the fix in #352, it would be useful to support await expressions in ExprLoop, ExprWhile, and ExprForLoop.
This commit my forked repo should enable writing loop and while loop in async closures. Tests have not checked their js syntax but testing on browser manually seems to be OK.

loop

However, a loop in itself is not so powerful without incrementing counts or assigning values, which are not supported yet in blocks.

For example,

view! {
    <button
        @click=$(async |_e| {
            let mut count = 0.0; // only F64Surrogate is currently supported for JS numbers
            loop {
                // count = count + 1.0; // currently unsupported
                // count += 1.0; // currently unsupported

                // do something
                if count > 0.0 {
                    break;
                }
            }
        })
    >"start loop"
    </button>
}

Therefore, supporting loops may be more useful when considered together with assignments and other expressions/operators.

An infinite loop can also cause a browser event handler to become unresponsive. However, this seems to be a consequence of the user's logic rather than something Topcoat needs to prevent.

while

If while expressions can be correctly generated in sync closures, it seems reasonable to support them in async ones as well.

for

for loops are more complicated because JavaScript provides several different forms of for loops, such as:

for (let i = 0; i < 10; i++) {
    // ...
}

for (const obj of iterable) {
    // ...
}

The appropriate representation may depend on the Rust expression being translated. There may also be performance differences between the available JavaScript forms depending on the particular use case, although I don't think Topcoat necessarily needs to optimize for one form universally.

More importantly, Rust for loops are based on iteration semantics, while JavaScript for...of requires a JavaScript iterable. Therefore, supporting ExprForLoop may require additional surrogate types or another mechanism for representing Rust iterables/collections in JavaScript.

So this may be worth discussing separately from the implementation of loop and while.

[EbaraKoji]

Related to #275.
This appears to be another consequence of the limitations of the current runtime $() expression approach.

[pikaju]

Thank you for reporting. We're currently working on some rendering internals, but after that I want to redo the runtime expression system so things like this will hopefully no longer be an issue.