Refactor provision of JavaScript engines to ExecutionContext

[jasonsummers]

Whilst upgrading 3rd party dependencies and target framework as part of #1024 I excluded upgrading JSPool from 2.0.1 to 4.0.0 due to braking changes.

Upon further investigation the JSPool package appears to be abandonware (last release ~10 years ago, last commit ~8 years ago).

Whilst researching alternatives I found that there is no way to reset an IJsEngine object provided by JavaScriptEngineSwitcher to it's original state and it's essentially dropped from the pool, negating the ability for the JavaScriptEnginePool to reuse the object. There could be some performance gains from the original initialisation of the object pool but I wonder if such an approach is necessary given the availability of decent compute both locally and remote.

I propose a refactor as follows:

• Remove the concept of JavaScriptEngine pooling; and
• Change the GetJavaScriptEnginePool to invoke a func or action to return a new engine provided by JavaScriptEngineSwitcher. This could be configurable so that users could provide their func, action or options/configuration to customise the IJsEngine returned from JavaScriptEngineSwitcher.

Thoughts and feedback greatly appreciated, especially if I've misunderstood the purpose of the JavaScriptEnginePool.

[daveaglick]

That makes sense to me, and it's sort of what we do for HttpClient as well (providing a factory method through the IExecutionContext). Since we're not actually "pooling" anything with this approach (which is fine), the factory method should just be called something like GetJavaScriptEngine(). Given that JavaScript use in Statiq is a bit of an edge case (it's really important when it's needed, but isn't a part of every generation flow), I think it's fine that we're not pooling the engines. I guess it remains to be seen how bad the startup time is to instantiate one, but I can't imagine it's horrible, especially if you're in a scenario that needs JavaScript in the first place.