Resolves #665

Solves the issue described in #665 with a different approach than the ticket suggests.

The implemented solution is to treat HTTP requests "atomic" if the following conditions are true:

• assume idempotence mode is enabled (this is the default)
• there are no side-effects that are belonging to the "write remote" category interleaved with the consumption of the response

If these conditions are true, and the execution is interrupted before the whole request is consumed (or the resources are dropped), during recovery we ignore the partially persisted entries and redo the request from the beginning. This is similar to how the mark_begin_operation/mark_end_operation host functions work for atomic regions, but with the additional guarantees that it checks for additional interleaved side effects.

If the conditions are not met, everything works as before, as in the request is not retried during recovery, and any further read from the response body leads to an error.

This new behavior is implemented in four major steps in this pull request:

1. Reusing the BeginRemoteWrite/EndRemoteWrite oplog entries which were previously only used when idempotence mode was turned off, so in case of HTTP requests the are always written to the oplog, no matter what the current idempotence mode is.
2. Changed when the EndRemoteWrite is emitted. This can happen in various places depending on the client consuming the response body or not. To implement this, ongoing HTTP requests are now tracked in the durable worker context with a HttpRequestState, which tracks the current "owner" that is responsible for writing the end marker. For example if consume is called on the response body, this responsibility is transferred to the input stream. This step required significant changes because to properly implement it, we need to be able to write end markers from resource drop functions. It is not possible to make these drop functions async, so a new synchronisation mechanism was introduced that allows sync host functions to enqueue oplog operations, and all async host functions (which are capable to manipulate the oplog) are awaiting the background processing of these enqueued operations before they execute. This can further refactored later so that all the oplog operations are only available in the returned permit, but this PR is not going that far.
3. Added a new WrappedFunctionType, called RemoteWriteBatched(begin_idx) which allows us to tag all oplog entries which belong to a "batched remote write", such as a HTTP request. They all refer to the oplog index of the BeginRemoteWrite entry emitted at the beginning of the sequence.
4. With all this set up, begin_function (which previously was only doing checks in replay mode when idempotence mode was turned off) can now look ahead to find the matching EndRemoteWrite entry, and if it cannot, it also checks whether there are any oplog entries which are not belonging to that particular batched operation. If there are not, it uses the same existing technique as the atomic region implementation, jumping to the end of the oplog, and introducing a deleted region for further replays.