[o11y] Deallocate STW handle early to manage its lifetime

[fhanau]

Hack: When the tail stream customEvent gets deallocated, we must also deallocate any JsRefs
allocated by it so that they are not outliving the tail worker isolate (they are not allowed
to be deallocated afterwards/by a different isolate). The JSG handler used for tail events
after the Onset event (maybeHandler) is owned by TailStreamTarget and must be deallocated as
part of the tail worker isolate. However, TailStreamTarget is both attached to the tail worker
customEvent and co-owned by the tailed worker (through capability in
TailStreamWriterState::Active). For the handler to be deallocated in the right isolate, we'd
accordingly need the tailed worker isolate to be deallocated before the tail worker isolate,
but this doesn't always seem to happen. Deallocate the handler so that the handler never
outlives the isolate here to ensure memory safety. The TailStreamTarget will report an error
if any events are reported after the handler has been deallocated.
TODO(o11y): See if we can enforce that the tail worker isolate lives longer than the tailed
worker isolate so that TailStreamTarget is always destroyed within this isolate. Alternatively,
we could forcibly disconnect the capnp RPC connection here to deallocate TailStreamTarget, but
this would result in exceptions on the tailed worker side if we try to deliver any events after
the connection has been disconnected; with the current approach this merely results in errors
being logged on the tail worker side.

Reviewers: The first commit (much smaller) is what matters, the second commit merely moves a class declaration to the header which is needed after adding the customEvent -> TailStreamTarget reference; compare using git diff -w.

[mar-cf]

Is there a strong reason to go with destroying the js ref when CustomEventImpl dies (which should happen before isolate destruction) over destroying the js ref when IoContext dies, before the isolate is destroyed? That may help decide if the additional maintenance burden over something like #5425 would be justified. Is there some additional explicit control or error handling opportunity that's gained here?