Refine exception handling responsibilities between the
DispatcherHandler and the HandlerAdapter.

This reverts commit d5e6f70483d4a6c8af3cc5e97e52a54e98199169.

Flux and Mono are used both for implementation and exposed at API
level to express 1 versus N semantic and to provide default Rx
operators:
- Flux<T> for multiple values Publisher (issue #48)
- Mono<T> for single value Publisher (issue #50)
- Mono<Void> for Publisher with no value (issue #49)

https://github.com/spring-projects/spring-reactive/issues/57

For those runtimes that don't directly support Reacitve Streams this
commit separates more formally Reactive Streams bridge code out of
the request and response implementations which become simple adapters
to the ServerHttpRequest/Response contracts like their RxNetty and
Reactor Net counterparts.

ServerHttpResponse implementations now immediately propagate
HttpHeaders changes as they so there is no need to call applyHeaders().

The writeHeaders from ServerHttpResponse is also removed. RxNetty and
Reactor Net both support implicitly completing if the handler
completes without explicitly writing the headers or the response body.

The "rxnetty" artifact is old (October 2015). There is now rxnetty-http
and other modules that have more recent snapshots (December 2015).

The DispatcherHandler now has an errorMapper property that is a
function for transforming errors. By default this property is set to an
instance of DispatcherHandlerExceptionMapper which wraps "standard"
framework exceptions and @ResponseStatus-annotated exceptions as
ResponseStatusException.

This makes it easy to handle the exceptions downstream uniformly.

This change adds a ResponseStatusException to associate an exception
with a status code at runtime. Along with that is an
ResponseStatusExceptionHandler that handles ResponseStatusException
by setting the response status.

The tests demonstrate failures at various phases of request processing
and the resulting error signals.

It brings along Servlet imports.

General improvements e.g. make use of Java 8 Stream. The main reason
for the refactoring however to tighten error handling. To that extent:

InvocableHandlerMethod turns all exceptions into Reactive Streams
error signals, in effect never allowing any Exceptions to bubble up.

HandlerMethodArgumentResolver may throw an Exception for sync resolution
or produce an error signal via the returned Publisher. Either way the
exception is consistently wrapped with helpful method argument details.
For the latter case using a custom mapError operator.

HandlerMethodArgumentResolver no longer needs to return Optional for
nullable argument values. Instead (for now) the defaultIfEmpty operator
of reactor.rx.Stream operator is used to ensure a default constant value
(called "NO_VALUE") is produced. That way an argument resolver may
produce 0..1 values where 0 means it did not resolve to any value and
that results in null passed as the argument value.

If a HandlerMethodArgumentResolver produces more than one value, all
additional values beyond the first one will be ignored with the help
of a custom "first" operator.

As HandlerMethod is invoked within the map operator, checked exceptions
are not allowed but instead of wrapping it in a runtime exception what
we really need is to unwrap the target exception for exception
resolution purposes. To this end concatMap is used to produce a nested
Publisher or an error Publisher with the unwrapped target exception.

Related to that InvocableHandlerMethod now returns
Publisher<HandlerResult> instead of Publisher<Object> so that no longer
needs to be externally mapped from Object to HandlerResult.

InvocableHandlerMethodTests provides tests for the above scenarios and
verifies the details of resulting error signals.

This commit also updates to the following dependencies:
 - Spring Framework 4.2.3.RELEASE
 - RxJava 1.1.0