This commit also improve significantly Kotlin extensions
documentation.

Issue: SPR-15127

Issue: SPR-15126

val context = GenericApplicationContext {
    registerBean<Foo>()
    registerBean { Bar(it.getBean<Foo>()) }
}

Issue: SPR-15126

Issue: SPR-15119

Issue: SPR-15118

Put the lambda parameter at the end and use a function
instead of a supplier to be able to register beans like this:

val context = GenericApplicationContext()
context.registerBean(Foo::class)
context.registerBean{ Bar(it.getBean(Foo::class)) }

Issue: SPR-15118

Based on an idea from Mario Arias, we can avoid requiring specifying
explicitly Supplier lambda type in Kotlin API by declaring the supplier
parameter as "crossinline supplier: () -> T" instead of
"supplier: Supplier<T>".

Issue: SPR-15118

For now if sharedEngine is set to false, a new
ScriptEngine instance is created for each request.

Issue: SPR-15063

Issue: SPR-15112

After the upgrade to JUnit Jupiter 5.0 M3, JUnit Jupiter tests in the
Spring build were no longer executed due to the introduction of a
default test class name pattern.

This commit addresses this issue by making use of the
@IncludeClassNamePatterns to specify that *TestCase test classes should
be executed within the org.springframework.test.context.junit.jupiter
package.

Issue: SPR-15106

Prior to this commit, the `ResourceHttpMessageConverter` would support
converting from an `HttpInputMessage` to a `InputStreamResource`. This
is valid when reading resources on the server side, but it's not
compatible with the way `RestTemplate` works.

The API exposed by `RestOperations` imply that the HTTP server response
should be fully consumed and properly closed by the time the `exchange`
method returns. In other words, this HTTP client does not support
streaming the HTTP response.

This commit allows the `ResourceHttpMessageConverter` to be configured
to disable read streaming when used in `RestTemplate`.

Issue: SPR-14882

* pr/1284:
  Implement MessagingException.toString()

Issue: SPR-15091
Closes gh-1284

* pr/1281:
  Remove use of Boolean constructors

Codacy warns us that there are several references to Boolean
constructors in the tests. Direct usage of the Boolean constructor is
discouraged and even deprecated in Java 9 [1]. Boolean constructor use
can easily be replaced with the constant instances.

This commit contains the following changes:

 - replace references to Boolean constructors with boolean constants in
   JSP tag tests
 - update the copyright year where necessary
 - BooleanComparatorTests is intentionally left unchanged as it should
   also work with the non-constant instances correctly

 [1] http://download.java.net/java/jdk9/docs/api/java/lang/Boolean.html#Boolean-boolean-

Issue: SPR-15076

* pr/1282:
  Avoid use of double constructor of BigDecimal

Codacy warns about an Error Prone [1] use of the double constructor of
BigDecimal in tests. The reason given is that it is a source of
precision loss if the number does not have an exact double
representation. The recommendation is to use the String constructor of
BigDecimal instead as it does not require using a lossy argument.

This commit contains the following changes:

 - replace usage of the double constructor of BigDecimal with the
   String constructor of BigDecimal in JdbcTemplateQueryTests
 - update the copyright year

 [1] http://errorprone.info/bugpattern/BigDecimalLiteralDouble

Issue: SPR-15077

Issue: SPR-15088

Kotlin 1.1-M04 has a bug that makes the generated bytecode
not compatible with Kotlin 1.0.x. This bug should be fixed in
Kotlin 1.1-M05.

* pr/1280:
  Remove String#toCharArray from ScriptUtils

ScriptUtils contains two calls to String#toCharArray for the sole
purpose to iterating over all chars in a String. Not only is this
unnecessary and can be replaced with String#charAt it also causes
additional allocator and heap pressure because String#toCharArray
rather than returning the backing array (which is gone in Java 9)
creates a copy.

This commit contains the following changes:

 - remove String#toCharArray from ScriptUtils and replace with
   String#charAt

Issue: SPR-15075

Prior to this commit, the `ResourceRegionHttpMessageConverter` would
rely on the default implementation of `getDefaultContentType` to guess
the default Content-Type of the resource region to be written to the
HTTP response. That implementation fetches the first media type
provided in the HTTP request "Accept" header.

This behavior is not correct when converting resources and this commits
aligns this converter with the `ResourceHttpMessageConverter` which uses
JAF to guess the correct Content-Type of the given resource, or just
returns "application/octet-stream" as a default value.

Issue: SPR-15041

Kotlin JSR 223 support currently requires kotlin-script-util
dependency (jcabi-aether, maven-core and aether-api can be
excluded since they are only used for live import of
dependencies and bring a lot of JARs in the classpath) and a
/META-INF/services/javax.script.ScriptEngineFactory
file specifying the ScriptEngineFactory to use, in that case
org.jetbrains.kotlin.script.jsr223.KotlinJsr223JvmLocalScriptEngineFactory.

Issue: SPR-15059

Needed for Kotlin script and JSR 223 support, and a good target
for Spring Framework 5.0 since it will allow features like generating
Java 8 bytecode, JDK 9 support, annotation array attribute single
value without arrayOf(), etc.

We ensure Kotlin 1.0 compatibility by setting apiVersion and
languageVersion compiler options to 1.0.

Issue: SPR-15059

Issue: SPR-15072

Issue: SPR-15071

Issue: SPR-15069

Issue: SPR-14692
Issue: SPR-15067