Discovered by fuzzing, but I'm not sure whether this can actually happen outside EmbeddedChannel.

Normally, HttpRequestDecoder will strictly follow the pattern `(HttpRequest HttpContent* LastHttpContent)*` for downstream handlers. However, when a downstream handler closes the channel inside a `channelRead` for a `HttpRequest`, this may reorder inputs, eg `HttpRequest HttpRequest LastHttpContent LastHttpContent`. This is mostly ByteToMessageDecoder's fault, and I'm not sure how to fix it in a performance-neutral way. Basically, `HttpRequestDecoder.channelInactive` is called while `HttpRequestDecoder.channelRead` is still running, so the next request gets inserted mid-request.

If this can only happen in EmbeddedChannel (which I'm not sure of), then we should just fix EmbeddedChannel instead.

…te something else

Motivation:

We need to ensure we only try to run tasks that were submitted for exectuion when we are not currently run other code in the EmbeddedChannel. We failed to do so and so coudl end up executing tasks directly while these should have been only run once the current execution is complete.

Modifications:

- Keep track of how deep our "execution stack" is and only run the pending tasks if we are sure it will not cause out of order problems
- Testcase

Result:

Correctly respect ordering