AbstractRequestBodyPublisher.onDataAvailable improvement

When in state DATA_AVAILABLE if there are simultaneous invocations of
AbstractRequestBodyPublisher.RequestBodySubscription.request and
ReadListener.onDataAvailable, the first one will process the available
data, the second one should not throw an exception because thus it will
signal to web container that there are problems while there are not.

Refactored Undertow support to register a response listener only when
the body is written to, as opposed to registering it at startup. The
reason for this is that getting the response channel from the
HttpServerExchange commits the status and response, making it impossible
to change them after the fact.

Fixed issue #119.

Make AbstractResponseBodySubscriber.onWritePossible thread-safe

When there are simultaneous invocations of onWritePossible, only the
first one should succeed. This can happens when
AbstractResponseBodySubscriber.onNext and
WriteListener.onWritePossible() are called respectively by the
application and the web container.

This is a port of the following commit, adapted for Java 8+:
https://github.com/spring-projects/spring-framework/commit/89396ff01ff159aa7df18e332f3888cf9ce3dc20

This is a temporary measure for M1 as the dependency will go away once
issue #116 is addressed.

Make AbstractResponseBodySubscriber.onSubscribe thread-safe

When there are simultaneous invocations of onSubscribe, only the first one should succeed, the rest should cancel the provided subscriptions

Reactored Servlet 3.1 and Undertow request support
(AbstractResponseBodySubscriber) to use an internal state machine,
making thread-safity a lot easier.

 - AbstractResponseBodySubscriber now checks if the current state is
   expected before changing to a new state.
 - Included comments by @violetagg

Currently ResponseEntityResultHandler is ordered lower than
ResponseBodyResultHandler by default whch means a ResponseEntity
should not be picked by the ResponseBodyResultHandler.

However as it is easy to have both ResponseEntity and @ResponseBody
e.g. in @RestControler (or even by mistake) and in general it makes
sense for ResponseBodyResultHandler to explicitly recognize and
ignore the ResponseEntity return type.

We now also check the default content type if the content type is
application/octet-stream as we do today.

Uncommented failing test that now passes.

Before this commit only ResponseEntity with async body was supported,
e.g. ResponseEntity<Mono<String>>

This commit also adds suppport for an asyn wrapper around,
e.g. Mono<ResponseEntity<String>.

Introduce separate test classes for each base class in the hierarchy
above @ResponseBody and ResponseEntity result handlers.

Also start porting existing unit test cases for @ResponseBody and
ResponseEntity return value handlers.

CodecHttpMessageConverter is now suitable for SSE since it now
handles default content type.

Reactored Servlet 3.1 and Undertow response support into an
AbstractResponseBodySubscriber that uses an internal state machine,
making thread-safity a lot easier.

Servlet flush will now occur on the next possible write if it cannot be
done immediately.

Flux<SseEvent> is Spring Web Reactive equivalent to Spring MVC
SseEmitter type. It allows to send Server-Sent Events in a reactive way.
Sending Flux<String> or Flux<Pojo> is equivalent to sending
Flux<SseEvent> with the data property set to the String or
Pojo value. For example:

@RestController
public class SseController {

	@RequestMapping("/sse/string")
	Flux<String> string() {
		return Flux.interval(Duration.ofSeconds(1)).map(l -> "foo " + l);
	}

	@RequestMapping("/sse/person")
	Flux<Person> person() {
		return Flux.interval(Duration.ofSeconds(1)).map(l -> new Person(Long.toString(l), "foo", "bar"));
	}

	@RequestMapping("/sse-raw")
	Flux<SseEvent> sse() {
		return Flux.interval(Duration.ofSeconds(1)).map(l -> {
			SseEvent event = new SseEvent();
			event.setId(Long.toString(l));
			event.setData("foo\nbar");
			event.setComment("bar\nbaz");
			return event;
		});
	}
}

This commit add flushing support thanks to the FlushingDataBuffer
wrapper that allows to identify the elements that should trigger a
flush.

This commit also fixes an issue in the HTTP client that used the
wrapper type instead of the element type. As a consequence, due
to type erasure, we now have to specify the type of the content
in DefaultHttpRequestBuilder#contentStream().