Fix setTimeout ID collisions.

[jp4a50]

workerd::api::gpu::AsyncRunner was using a different instance of TimeoutId::Generator than is used for setTimeout calls from JS.

I fix this by moving ownership of the TimeoutIdGenerator into the TimeoutManagerImpl itself.

In the case of gpu::AsyncRunner, it doesn't look like there's any need to generate an ID for the timeout, so we could alternatively approach this by re-using the timeout logic but not generating an ID in order to avoid silently using up timeout ID values under the hood. Not sure whether it's worth it.

[jp4a50]

Hmm, actually, this does change the semantics of setTimeout/clearTimeout across multiple requests that execute within the same global scope.

Currently, I think it would be possible to clear a timeout set by a previous request.

Is this something which we would want to continue to support, or are we OK just preventing this? @jasnell

[kentonv]

This was intentionally designed so that IDs returned by setTimeout() are unique across the isolate, not just a single request. Note that the design doesn't allow one request to clear another request's timeouts, it only ensures non-overlapping IDs. This could be important if someone stored IDs in a global map or something -- not sure why someone would want to do that, but it's possible.

So, I don't think we should make this change as-is. Instead, the GPU API should probably use the timeout ID generator from the global scope object.

Incidentally, I don't think the GPU API could be causing the ID conflicts we've seen in production, since this API isn't currently available in production.