This commit makes it possible for handler functions to return
asynchronous status codes and headers, by making HandlerFunction.handle
return a Mono<ServerResponse> instead of a ServerResponse. As a
consequence, all other types that deal with HandlerFunctions
(RouterFunction, HandlerFilterFunction, etc.) had to change as well.

However, when combining the above change with method references (a very
typical use case), resulting signatures would have been something like:

```
public Mono<ServerResponse<Mono<Person>>> getPerson(ServerRequest request)
```

which was too ugly to consider, especially the two uses of Mono. It was
considered to merge ServerResponse with the last Mono, essentialy making
ServerResponse always contain a Publisher, but this had unfortunate
consequences in view rendering.

It was therefore decided to drop the parameterization of ServerResponse,
as the only usage of the extra type information was to manipulate the
response objects in a filter. Even before the above change this was
suggested; it just made the change even more necessary.

As a consequence, `BodyInserter` could be turned into a real
`FunctionalInterface`, which resulted in changes in ClientRequest.

We did, however, make HandlerFunction.handle return a `Mono<? extends
ServerResponse>`, adding little complexity, but allowing for
future `ServerResponse` subtypes that do expose type information, if
it's needed. For instance, a RenderingResponse could expose the view
name and model.

Issue: SPR-14870

This commit changes web.reactive.function to reflect the introduction of
the new WebClient. Changes include:

- Request -> ServerRequest
- Response -> ServerResponse
- FilterFunction -> HandlerFilterFunction
- StrategiesSupplier -> HandlerStrategies

This commit introduces a new, functional web programming model in the
org.springframework.web.reactive.function package. The key types
are:

 - Request and Response are new Java 8-DSLs for access to the HTTP
   request and response
 - HandlerFunction represents a function to handle a request to a
   response
 - RoutingFunction maps a request to a HandlerFunction
 - FilterFunction filters a routing as defined by a RoutingFunction
 - RequestPredicate is used by Router to create RoutingFunctions
 - RequestPredicates offers common RequestPredicate instances

Issue: SPR-14432

This change updates all cases where callbacks are invoked to catch and
suppress errors (since there is not match to do with and error from
a callback be it success or failure).

Also updated is the contract itself to clarify this and emphasize the
callbacks are really notifications for the outcome of the
ListenableFuture not the callbacks themselves.

Issue: SPR-13785

Make it possible to use a ListenableFuture with Java 8
lambda expressions, using a syntax like
listenableFuture.addCallback(() -> ..., () -> ...);

Issue: SPR-11820

Added extension to Future with capabilities for registering callbacks
when the future is complete.

- Added ListenableFuture, ListenableFutureCallback,
  ListenableFutureCallbackRegistry, and ListenableFutureTask.
- Using ListenableFuture in AsyncRestOperations/AsyncRestTemplate.
- Added AsyncListenableTaskExecutor, implemented in
  SimpleAsyncTaskExecutor.
- Added FutureAdapter and ListenableFutureAdapter.

Consolidates new, messaging-related classes from spring-context and
spring-websocket into one module.

Minor formatting and Javadoc changes.

Prior to this change, CallbacksSecurityTests#testContainerPrivileges was
@Ignored because it caused the build to fail under Gradle. After some
analysis, the root cause was determined to be the fact that (a) a
restrictive SecurityManager is active during the running of this test,
and (b), Gradle intercepts System.out and routes it through its internal
LogBack-based logging system. LogBack requires a call to
Class#getClassLoader when handling logging statements, and the
SecurityManager disallows this call, thus raising the error that fails
the build.

This commit solves the problem by eliminating the System.out.println
call in question and removing the @Ignore annotation from the test. The
console output was diagnostic in nature anyway, and not required for the
successful execution of the test's assertions.

Issue: SPR-10074

  find . -type f -name "*.java" -or -name "*.aj" | \
    xargs perl -p -i -e "s/[ \t]*$//g" {} \;

Issue: SPR-10127

This renaming more intuitively expresses the relationship between
subprojects and the JAR artifacts they produce.

Tracking history across these renames is possible, but it requires
use of the --follow flag to `git log`, for example

    $ git log spring-aop/src/main/java/org/springframework/aop/Advisor.java

will show history up until the renaming event, where

    $ git log --follow spring-aop/src/main/java/org/springframework/aop/Advisor.java

will show history for all changes to the file, before and after the
renaming.

See http://chrisbeams.com/git-diff-across-renamed-directories

Prior to this change, roughly 5% (~300 out of 6000+) of files under the
source tree had CRLF line endings as opposed to the majority which have
LF endings.

This change normalizes these files to LF for consistency going forward.

Command used:

$ git ls-files | xargs file | grep CRLF | cut -d":" -f1 | xargs dos2unix

Issue: SPR-5608

Prior to this change, roughly 5% (~300 out of 6000+) of files under the
source tree had CRLF line endings as opposed to the majority which have
LF endings.

This change normalizes these files to LF for consistency going forward.

Command used:

$ git ls-files | xargs file | grep CRLF | cut -d":" -f1 | xargs dos2unix

Issue: SPR-5608