[browser][MT] GC, threadpool and some JS interop improvements

[pavelsavara]

This makes GC, threadpool and some JS interop scenarios work on the mini sample

Changes

• JSSynchronizationContext - could be installed on multiple threads
  • has target thread, instead of just main thread
  • new InstallWebWorkerInterop and UninstallWebWorkerInterop
  • JSSynchronizationContext is automatically installed on the main thread
  • new mono_target_thread_schedule_background_job helps to implement that
  • external_eventloop and thread_id private fields of Thread are accessed via reflection. I don't know about better way right now.
• new System.Runtime.InteropServices.JavaScript.WebWorker for starting threads dedicated to JS interop
  • Run method accepts synchronous Action.
    • enables calling synchronous JSImport/JSExport
    • since you can't (async) import JS module, you could only call runtime code which is already loaded into the webworker
    • maybe we would not have this signature as public API as it's not very useful to end user
  • RunAsync accepts Func<Task> and enables JS interop as well as async JSImport/JSExport.
    • this is necessary for any JSHost.ImportAsync
    • for any Http or WS client
    • callback needs to keep the returned Task unresolved while working with JS/promises/events/network
  • user would be responsible for cleanup of the JS global web worker state, as the same web worker could be re-used later.
  • the idea is that WebWorker is un-managed resource
  • drafted forceDisposeProxies which is called at the end of WebWorker run

Fixes & tests

• added MONO_ENTER_GC_UNSAFE/MONO_EXIT_GC_UNSAFE into lifo-semaphore.c callbacks
• added MONO_ENTER_GC_UNSAFE/MONO_EXIT_GC_UNSAFE into mono_wasm_invoke_method_bound
• added mono_threads_wasm_on_thread_detached callback for easier tracking of web workers
• added set_thread_info which creates function globalThis.monoThreadInfo on the worker. It's easy to look at in the browser dev tools. Just in debug build of the runtime.
• use Module.safeSetTimeout for jobs
• GC + timers mini-test in the browser-threads-minimal
• native thread ID as prefix for worker JS logging
• fixed SystemNative_GetCpuUtilization

Next

• WebWorker API is just early sketch. Do we want to make it IDisposable instance instead ?
• threads are detached slowly and so the sample needs at least 6 web workers in the pool.
• this doesn't yet run unit tests very well
• perhaps we could asynchronously allocate more web workers into emscripten pool
• we could also allocate new web worker for each WebWorker.Run, maybe with a flag parameter
• finish implementation of forceDisposeProxies

[ghost]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

work in progress

Author:	pavelsavara
Assignees:	pavelsavara
Labels:	arch-wasm, area-System.Threading
Milestone:	8.0.0

[pavelsavara]

/azp run runtime-wasm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[pavelsavara]

/azp run runtime-wasm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[pavelsavara]

I created #87314 and #87315 for MT debugger failure on CI

[pavelsavara]

/azp run runtime-wasm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[pavelsavara]

/azp run runtime-wasm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[pavelsavara]

/azp run runtime-wasm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[pavelsavara]

/azp run runtime-wasm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[pavelsavara]

CI failures are #87414 and #87423