Adding an interface to query readiness to accept requests

This would serve a few purposes:

• As an instance reuse "handshake" between the caller and handler, allowing e.g. a host to drop an instance that won't accept any further requests or a guest to eagerly perform some expensive state reset.

• As a form of flow control (back pressure) for entire requests. This is useful in load-balancer-like situations where the sender wants to pick from only handler(s) that are ready to process a request.

• A way for handlers to explicitly signal concurrency support.

A rough draft:

interface readiness {
  /// May be called to query the handler's readiness to accept request(s).
  /// - Blocks if the handler is not ready to accept any more requests but may become ready in the future.
  /// - Returns `ok(n)` when the handler is ready to accept up to `n` concurrent requests.
  /// - Returns `err` if this instance won't ever accept another request (instead of exiting).
  /// - Returns `ok(0)` if the handler cannot report its readiness; the caller will just have to take
  ///   its chances on `handle` blocking (maybe better as an error variant?).
  ready: async func() -> result<u32>;
}

This would be added to the proxy world or the proposed service world. Alternatively this function could be added to the handler interface, though I'm not sure that it is applicable to generic "outbound http" imports.

Start by reading the proposed service world in issue #793 and compare it with the proxy and handler interfaces. Review the readiness WIT draft and the discussion about request back pressure, concurrency, and outbound HTTP applicability. Done means reaching agreement on the interface location and semantics, including the result cases and blocking behavior.