Dispatch

use emscripten job queue in the target thread instead of JSSynchronizationContext to call cross-thread JS functions.

This has following benefits

• the target thread doesn't have to be managed thread.
  • this contributes to the goal of avoiding managed code on UI thread to avoid clashing with GC stop-the-world
• smaller allocation of the job object
• probably faster than interp of the JSSynchronizationContext
• doesn't need to wait for schedule_background_exec -> setTimeout tick

Cross-thread asynchronous

All of them are fire-and-forget messages

• ReleaseCSOwnedObjectPost
• InvokeJSImportAsyncPost
• ResolveOrRejectPromisePost & CancelPromisePost
  • this is complex case because there could be (rare) racing threads.
  • The one with JS objects is resolving the Task/Promise and another thread is triggering cancellation.
  • We need to keep the GCHandle of the Task/Promise alive so, that the async messages don't have use-after-free problem.
  • After this PR we don't have the use-after-free problem
  • But we leak the GCHandle instead, only when there is a race condition.
  • The problem will become even more complex, once we want to also resolve/reject the promise->task by async message.

Cross-thread synchronous

• InvokeJSFunctionSend & InvokeJSImportSyncSend
  • both of them are blocking the caller in native code via GC friendly mono_coop_sem_wait
  • I speculate that target thread is unable to .Wait for too long
• JSSynchronizationContext.Send now throws PNSE on JS threads via ThrowOnBlockingWaitOnJSInteropThread
• ConsolePal.Clear - ICAL instead of JSImport - more in line the rest of with posix console pal.

Other

• deleted legacy interop ICAL dead code