This PR:

• Adds a new autogate, INCREASE_EXTERNAL_MEMORY_ADJUSTMENT_FOR_FETCH.
• Removes an old autogate, FETCH_REQUEST_MEMORY_ADJUSTMENT.
• Increases the external memory adjustment for fetch()es from 3 KiB to 8 KiB when the new autogate is on.
• Moves the external memory adjustment to IoContext::getSubrequestNoChecks() so that it covers all subrequests, not just fetch() subrequests.
• Adds the same external memory adjustment to Cache API subrequests.

In testing, I have discovered that the real C++ heap overhead of fetch() is 8 KiB if it ends up being queued in our concurrent connection limiter, and 32 KiB if it manages to establish a connection. So, this change brings the external memory adjustment closer to the actual unaccounted-for memory, regardless of whether or not the fetch() is queued. Also note that other factors, such as header size, could increase the overhead significantly higher, but probably don't much influence the mean or median overhead.

Moving the external memory adjustment from just fetch() to all subrequests is probably the most consequential part of this change, and worth discussing.

The dilemma is this: We'd like to relax the concurrent connection limiting behavior and rely solely on heap pressure to force the Worker to keep its concurrent subrequest connection count under control. So, it makes sense to apply this external memory adjustment to all subrequest types which end up establishing a network connection, not just fetch(). But, we can't know if a subrequest will actually need to establish a network connection until much deeper in our internal integration, where it would be an abstraction leak to add an external memory adjustment. This is already even true for fetch() itself -- it may invoke a Service Binding and not go over the network, after all.

I think expanding the external memory adjustment to cover all subrequest types is the right thing to do largely because all of the alternatives seem worse: We don't want to leave any potential network subrequests unaccounted for; we don't want maintain a a brittle, whackamole solution early in the call graph (close to fetch(), etc.); and we don't want to implement an abstraction leak later in the call graph (close to the actual network connection).

In a more positive light, I would also argue that applying the memory adjustment to subrequests unconditionally has the nice property that it applies pressure on the root originator of pressure in the system: if a Worker issues 100 fetch()es to 100 different service bindings, each of which then establishes one network connection, the root Worker receives the majority of the memory pressure to constrain its concurrency.