Issue: SPR-14958

Issue: SPR-13188

Issue: SPR-13188

This commit also fixes broken javadoc links and code references.

Issue: SPR-13188

Issue: SPR-14201

Issue: SPR-13567

- Delete unused imports
- Delete unused code
- Clean up warnings

JodaTimeFormatterRegistrar defensively checks whether Joda-Time 2.x is present (for Joda-Time 1.x tolerance on the classpath)

Also switches 4.2.4's new formatter implementations to package visibility, just in case they'll be superseded by another variant in the future.

Issue: SPR-13730

Issue: SPR-13518

Issue: SPR-13721

Issue: SPR-12926

Moved @Uses annotations to org.springframework.lang; fixed Base64Utils to declare Java 8, and fixed PathResource's declaration to refer to Java 7.

Issue: SPR-11604

Animal sniffer provides tools to assist verifying that classes
compiled with a newer JDK are compatible with an older JDK.

This integratesthe latest version of the tool (1.11) that
permits the use of custom annotations. Added @UsesJava7,
@UsesJava8 and @UsesSunHttpServer and annotated the few places
where we rely on a specific environment.

The verification process can be invoked by running the 'sniff'
task.

Issue: SPR-11604

polishing

Issue: SPR-11259

Also adding several further Joda-Time converters for consistency with JSR-310 converters.

Issue: SPR-11259

Apply consistent styling to new classes introduced in Spring 4.0.

- Javadoc line wrapping, whitespace and formatting
- General code whitespace
- Consistent Assert.notNull messages

Comprehensive update to the framework's TimeZone handling, including a new TimeZoneAwareLocaleContext and a LocaleContextResolver for Spring MVC

A few noteworthy minor changes: LocaleContext.getLocale() may return null in special cases (not by default), which our own accessing classes are able to handle now. If there is a non-null TimeZone user setting, we're exposing it to all collaborating libraries, in particular to JSTL, Velocity and JasperReports. Our JSR-310 and Joda-Time support falls back to checking the general LocaleContext TimeZone now, adapting it to their time zone types, if no more specific setting has been provided. Our DefaultConversionService has TimeZone<->ZoneId converters registered. And finally, we're using a custom parseTimeZoneString method now that doesn't accept the TimeZone.getTimeZone(String) GMT fallback for an invalid time zone id anymore.

Issue: SPR-1528

Issue: SPR-10130

This is largely derived from our existing Joda-Time support, with corresponding classes wherever possible.

Issue: SPR-9641