Add ability to `__optimize` functions at site of `__optimize` call.

[cblappert]

Currently all optimized functions are evaluated at the end of global initialization, possibly with any parent optimized functions' effects applied. This model works well for pure callbacks where we know they'll be called sometime after the end of global initialization, but we don't know when.

There's another case we would like to support for optimized functions, where we know where the function will be called, but maybe we don't know the inputs or how many times it will be called:

let x = __abstract("array", "modelVariableX");
x.map((entry) => { /* do a bunch of work */ });

In this case, we could treat the arrow function passed to map as an optimized function, but then we need to evaluate it at the point of the map call for the environment to be correct.

[cblappert]

Copied with some modifications from @NTillmann's comment on #2303:

To revisit in the future: In what initial state should a nested optimized function be evaluated in?

• The state after the outer optimized function is done (appropriate for event handlers), what is currently done
• or in the state right where the __optimize call happened (appropriate for functions passed to .map etc. on arrays), what this Issue suggests adding
• or in a way where the entire environment is made abstract (the default if we don't know better?), something for the future for general use of optimized functions

[NTillmann]

The state right where the __optimize call happened.

This is currently enabled for special cases like the array .map function but is guarded by the arrayNestedOptimizedFunctionsEnabled option. This needs to be finished. Would be nice if it was exposed via another general primitive, maybe __optimizeHere, or __optimize could get a second parameter.