This PR implements support for defining a connect() handler, which is behind an experimental compat flag for now. This is largely based on James' previous PR for this (#1429), but includes changes to switch to the socket-based API, drop the deferred proxying code, add more tests, add proper tracing support etc. I don't have a strong background on how workerd/KJ streams work yet – there might be trivial issues in how streams are being used. You'll notice that this PR differs from the internal spec in that it still provides an event to the tail handler and there are several other issues – see the open questions below where I'm looking for input on how to best address this.

Open questions:

• This still provides a ConnectEvent with a cfJson field to the JS connect handler: Based on the internal discussion, a cfJson field should not be needed, but the parameters set to be provided in server.c++ (clientIp, clientPid, clientUid) feel like they might be useful – should there be a different way to provide such metadata? Otherwise I'll change this to just provide a plain socket as the first parameter to the handler (as discussed on the internal spec)
• [Unchanged from previous PR] The headers provided by the incoming connect() call should be passed through instead of being discarded, right?
• We currently construct a neuterable stream in ServiceWorkerGlobalScope::connect() without really needing to do so – there should be a cleaner way to get an owned AsyncIoStream?
• I assume that HTTP response codes are not needed for TCP? This is relevant for the tail worker return event, which has an optional return code.
• Is there cleanup potential in WorkerEntrypoint::connect()? A lot of this is adapted from request(), there's likely some logic towards the end that's only needed when doing deferred proxying
• Do we need to use HttpRewriter at all for TCP in server.c++? server.c++'s TcpListener has remnants of support for this left, but since it's not dealing with HTTP, rewriting might not be needed
• Windows tests are failing – perhaps related to EW-9330 Implement connect() handler #6059 (comment)?
• Miniflare tests are failing – looks like the new code path actually does get enabled for them based on having the "experimental" compat flag. As seen in https://github.com/cloudflare/workerd/actions/runs/22805783114/job/66155261833?pr=6059 (CI run on commit 7713c75 where the wrangler CI jobs were put in a different order), the miniflare tests are the only failing ones Add support for worker connect handler in miniflare workers-sdk#12775 has been merged, the next daily miniflare should be sufficient to fix CI and unblock this PR.
• I'll clean up/squash commits before merge.

The following assumptions were made in implementing this:

• The affected tests have been marked with the Bazel "exclusive" tag and will run one at a time to avoid flakes due to tests trying to use the same TCP port at the same time – I considered using different ports in different tests but we'd still have the issue between regular and @all-autogates variants; the Bazel sandbox might also offer ways to work around this but as long as Bazel does not support sandboxing on Windows we'd still be facing flakes in CI. If there's concerns about a CI slowdown here, I can implement a mechanism to provide a random unused port instead.
• I'm assuming that with the socket-based API, neuterable streams are not needed since deferred proxying does not need to be implemented.
• We may want TLS support in the future, but this is not included for now.
• I'm assuming that connect_handler doesn't need to be a user span for now, just how fetch_handler isn't one.
• Kenton suggested adding a proxyTo() function – I've implemented this but it can land separately, this is available on the felix/030226-proxyTo branch.
• After factoring out some code shared with the HTTP/fetch code path there's some remaining code duplication – lmk if you can point to any more spots that would be good candidates for deduplication that wouldn't make code harder to maintain.