[Proxying][NFC] Move deferred cleanup logic to em_task_queue

[tlively]

We previously had a scheme to defer freeing of em_proyxing_queues until there
were no more outstanding references to their em_task_queues sitting in
message queues. Since the notification messages only ever contain references to
em_task_queues and not the em_proxying_queues, move the deferred cleanup
logic to the em_task_queue layer from the em_proxying_queue layer. This
slightly simplifies the code and is a cleaner separation of concerns.

This is NFC as far as users are concerned, and the code is moved with only two
changes to internal behavior. First, we now use a trylock when culling zombies
to avoid blocking when multiple threads are creating em_task_queues at the
same time. Second, we now enqueue zombie queues at the tail of the zombie list
instead of the head because FIFO behavior seems fairer.

The test for the zombie culling behavior is necessarily less precise now because
it the objects with deferred cleanup are no longer directly user-visible. The
test still does its job, though.

[tlively]

Current dependencies on/for this PR:

• main
  • PR [Proxying][NFC] Move deferred cleanup logic to em_task_queue #18851 👈
    • PR [Proxying] Send messages via in-memory mailbox queues #18852
      • PR [Proxying] Cancel proxied work when the worker thread dies #18741
        • PR [Proxying] Update proxying with callback to support cancellation #18776
          • PR [Proxying] Add emscripten_proxy_callback_with_ctx #18810
            • PR [Proxying] Add proxying functions that return promises #18825
              • PR [Proxying] Use Atomics.waitAsync to receive proxying notifications #18861
                • PR Remove unnecessary EXIT_RUNTIME setting from proxying tests #18873

This comment was auto-generated by Graphite.

[sbc100]

Does hit not risk counting other misc allocations? (I guess if it ever does this test will just start failing or flaking)..

[tlively]

Yeah, right now this doesn't seem to be a problem, but I could imagine that this test would start flaking in the future. At some point we might want to remove it entirely in favor of a test that builds and tests the internal em_task_queue implementation directly.