Fix typos in Javadoc
Polish @Imports search code

Issue: SPR-9925
Assess claims made in SPR-9799

This commit validates the claims made in SPR-9799.

 - Spr9799XmlConfigTests demonstrates that a WAC is not always necessary
   when integration testing with XML configuration that uses
   <mvc:annotation-driven />.

 - Spr9799AnnotationConfigTests demonstrates that a WAC is in fact
   necessary when integration testing with a configuration class that
   uses @EnableWebMvc.

Issue: SPR-9799
Delete unused import
Update changelog

Added missing JIRA issue IDs.
Update changelog
Fix typo in changelog
Remove need to manually set wrapper GRADLE_OPTS

Replace the wrapper task with a variant that automatically adds the
appropriate GRADLE_OPTS to the shell and bat files.
Restore GRADLE_OPTS from wrappers

Run the updated build script to generate gradlew and gradlew.bat files
that have correct GRADLE_OPTS.
Peek into the content for @RequestBody(required=false)

For @RequestBody(required=false), it is not sufficient to check if the
InputStream is null. This change reads the first byte of the request
InputStream to determine if the request body is empty or not.

If the InputStream implementation supports mark(int) and reset(), then
we use those. Otherwise we use PushbackInputStream to read and unread
the first byte.

All of this is done only if the required flag of @RequestBody is set
to "false" (default is "true").

Issue: SPR-9942
Fix issue with generic @RequestBody arguments

The original commit c9b7b1 ensured the ability to read parameterized
type @RequestBody arguments via GenericHttpMessageConverter (e.g.
application/json and List<String>). However, it also affected the
ability to read @RequestBody arguments that happen are parameterized
but aren't treated as such (e.g. application/x-www-form-urlencoded and
MultiValueMap<String, String>). This commit corrects the issue.

Issue: SPR-9570
Remove -XX:MaxHeapSize=256m from default GRADLE_OPTS

This setting was causing failures in the CI build, and was not present
prior to the recent updates to gradle wrapper generation.

This commit also simplifies the gradle wrapper customizations by placing
the logic in a doLast block within the original 'wrapper' task, as
to creating a second wrapper task and extending from the first.
Restore -XX:MaxHeapSize=256m for gradlew.bat

Restore the MaxHeapSize setting for the Windows build only.
Polish
Refine hamcrest dependency in spring-test-mvc project

1) removed the hamcrest-all dependency requirement and replaced it with
the more focused hamcrest-library dependency

2) added MatcherAssertionErrors as a replacement of
org.hamcrest.MatcherAssert, which in hamcrest 1.1 is only available
through the hamcrest-all dependency (and not in hamcrest-core nor in
the hamcrest embedded in JUnit 4.4 through 4.8)

3) changed the required hamcrest version from 1.1 to 1.3 and made sure
the spring-test-mvc project does not rely on newer hamcrest
functionality without checking if it is available first

Applications that already depend on older versions of hamcrest
(in particular 1.1) via hamcrest-library, hamcrest-all or as part of
junit 4.4 through 4.8 should not be disrupted if they add spring-test
but may wish to exclude the hamcrest-library transitive dependency
from spring-test in order to avoid extra jars in the classpath

Applications that depend on hamcrest 1.3 should not have to do anything

Issue: SPR-9940
Initialize FrameworkServlet property sources eagerly

Prior to this change,
FrameworkServlet#configureAndRefreshWebApplicationContext called
 #postProcessWebApplicationContext(wac) and #applyInitializers(wac)
prior to #refresh, but because servlet-based property source stubs were
not replaced until #refresh, any post-processing or initialization
routines could not benefit from accessing the Environment to retrieve
properties from the ServletContext or ServletConfig.

The workaround to this problem is detailed in SPR-9610 - the user simply
needed to call WebApplicationContextUtils#initServletPropertySources
manually within their ApplicationContextInitializer (or overridden
 #postProcessWebApplicationContext method)

This commit ensures that
FrameworkServlet#configureAndRefreshWebApplicationContext calls
WebApplicationContextUtils#initServletPropertySources eagerly, prior to
invoking #postProcessWebApplicationContext and #applyInitializers.
Related Javadoc has also been updated throughout to clarify the behavior
of #initServletPropertySources, when it can be called and what the
effects are, etc.

Note also that a reproduction issue was added to demonstrate the problem
and verify its resolution [1].

[1]: https://github.com/SpringSource/spring-framework-issues/tree/master/SPR-9610

Issue: SPR-9610