[browser][MT] Keep track of additional JS keepalive sources for worker threads

[lambdageek]

In #84492 we added WebWorkerEventLoop.HasUnsettledInteropPromises that will be used by #84494 to keep a threadpool worker thread alive in the JS event loop as long as some promise exists that is needed by a JSImported Task in C#.

There could be, however, other reasons why a threadpool worker thread may need to stay alive: if the JS code has used setTimeout with a callback that depends on a JS proxy of a C# function or object, for example. These additional scenarios can be somewhat covered by creating promises that the C# code could await, but we should also have more robust tracking in our interop layer.

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

Issue Details

---

In #84492 we added WebWorkerEventLoop.HasUnsettledInteropPromises that will be used by #84494 to keep a threadpool worker thread alive in the JS event loop as long as some promise exists that is needed by a JSImported Task in C#.

There could be, however, other reasons why a threadpool worker thread may need to stay alive: if the JS code has used setTimeout with a callback that depends on a JS proxy of a C# function or object, for example. These additional scenarios can be somewhat covered by creating promises that the C# code could await, but we should also have more robust tracking in our interop layer.

Author:	lambdageek
Assignees:	-
Labels:	arch-wasm, area-System.Runtime.InteropServices.JavaScript
Milestone:	-

[lambdageek]

/cc @pavelsavara