Prior to this commit, FreeMarkerView used the system default charset to
render. This commit switches this by defaulting to UTF-8, if no charset
is specified in the content type.

 - Add contentType parameter to AbstractView.renderInternal, used to
 determine the charset contained therein
 - Adds a defaultCharset property to AbstractView and
 ViewResolverSupport.

Changed View's render method from taking a HandlerResult to taking a
Map<String, ?>, in order to facilitate scenarios where a HandlerResult
is not available (i.e. web.reactive.function).

Issue: SPR-14522

Issue: SPR-14159

Ensure type-level Javadoc in every class, comply with guidelines for
80 char on Javadoc, and minor polish.

HandlerAdapter's should always be able to provide a MethodParameter
which in turn ensures that HandlerResultHandler's have full type
information from method declarations.

This commit also introduces ResolvableMethod for use in tests to make
it easy to obtain MethodParameter return types.

Issue: #128

Removed in favor of accessing the factory from the response.

ViewResolutionResultHandler and ResponseBodyResultHandler now share
a common base class ContentNegotiatingResultHandlerSupport that
supports content negotiation.

For view resolution we compare against the supported media types of
resolved View instances, which may include default View's delegating
to an HttpMessageConverter (e.g. JSON, XML, rendering).

View now returns Mono<Void> rather than Flux<DataBuffer> which aligns
more closely with the reactive HttpMessageConverter vs the Encoder.

The change was prompted by the upcoming implementation of a View that
delegates to an existing HttpMessageConverter e.g. for JSON, XML.

The resulting change also brings the reactive View closer in spirit to
the View from spring-webmvc which returns void.

This commit adds support for Model-related return values types such as
Map, Model, @ModelAttribute annotated, and non-simple types, which
helps to clarify the logic in ViewResolutionResultHandler.

This commit ensures correct handling for Mono.empty() return value
where the declared return type is Mono<String> or Mono<View>.

While View and ViewResolver play the same role as in spring-webmvc they
are now abstracted behind the HandlerResultHandler abstraction so that
top-level contracts don't reference them and the DispatcherHandler is
also unaware of their existence.

Furthermore view resolution and response body handling which are now at
the same level of abstraction (each is a HandlerResultHandler) will
also share code for content negotiation, so it makes sense for them to
be side by side.

This commit moves the reactive.view package to reactive.result.view
with the View and ViewResolver contracts (previously in the top-level
reactive package) also moving there.