There is really no need for a result handler dedicated to a void
return value and it's actually problematic to have it.

Each result handler treats void as necessary. For an @ResponseBody
method it means an empty body. For view resolution it means no specific
value was returned and we should procede with selecting a default view
name. Having a dedicated void result handler can interfere with this
especially since view resolution needs to be last in order.

At the same time there are cases when no result handling is needed
and the response is fully handled within the HandlerAdapter. This is
the case with WebHandler and the SimpleHandlerAdapter. For that case
we simply return mono.then(aVoid -> Mono.empty()) which effectively
returns an empty Mono and no result handling follows. The
HandlerAdapter already says you can return no values at all if the
response is fully handled.

JndiPropertySource defensively skips invalid JNDI lookup for property name with colon in resource-ref mode

Issue: SPR-14518

With the current state machine
- the implementation can hang after the last element when executing
on Jetty.
- in some cases there will be no flush after the last
Publisher<DataBuffer>.

AbstractResponseBodyProcessor.onError and
AbstractResponseBodyFlushProcessor.onError will be invoked when:
- The Publisher wants to signal with onError that there are failures.
Once onError is invoked the Subscription should be considered canceled.
- The internal implementation wants to signal with onError that there
are failures. In this use case the implementation should invoke
Subscription.cancel()

This commit changes writeWithInternal(Publisher<DataBuffer> body).
It is implemented as writeAndFlushWith(Mono.just(body)).

Issue: SPR-14517

Expose DefaultSubscriptionRegistry's cache limit through SimpleBrokerMessageHandler and MessageBrokerRegistry

Issue: SPR-14516

Issue: SPR-13344

Issue: SPR-14511

Issue: SPR-13188

DataSourceUtils moved to main core.io.buffer package.
Consistently named Jackson2JsonDecoder/Encoder and Jaxb2XmlDecoder/Encoder.
Plenty of related polishing.

Drop JpaSystemException(PersistenceException) constructor to avoid ambiguity in HibernateJpaVendorAdapter

Hibernate 5.2's HibernateException extends PersistenceException, leading to a different constructor compiled into the bytecode, breaking compatibility with Hibernate 5.0 at runtime.

Issue: SPR-13827

Issue: SPR-14497

The CORS section is now ahead of
"Integrating with other web frameworks" and "WebSocket Support".

Issue: SPR-13344

Issue: SPR-14430

Issue: SPR-14486

This commit also drops the now-unused CUSTOM_COMPILATION test group and the outdated JavaVersion class.

Issue: SPR-10423

* pr/1112:
  Polish contribution
  Polish Javadoc

Closes gh-1112

See gh-1112

Issue: SPR-14509

Issue: SPR-13188