Delete work-around for Ant 1.8 in Gradle build

Ant 1.9.2 is packaged with Gradle since release 1.10. Since the Spring
Framework build now uses Gradle 1.11, there is no longer a need for the
"javac1.7" build compiler work-around for the spring-oxm module.
Clean up warnings that show up in Gradle build
Upgraded JSP build dependency to 2.2
Favor 'local' annotations over inherited ones

Prior to this commit, the implementations of findAnnotation() in
AnnotationUtils and getAnnotationAttributes() in AnnotatedElementUtils
favored inherited annotations and inherited composed annotations over
composed annotations that are declared closer to the starting class
passed to these methods.

This commit addresses this issue as follows:

- Refactored AnnotationUtils to use getDeclaredAnnotation() and
  getDeclaredAnnotations() instead of getAnnotation() and
  getAnnotations() where appropriate.

- AnnotatedElementUtils.doProcess() supports a traverseClassHierarchy
  flag to control whether the class hierarchy should be traversed,
  using getDeclaredAnnotations() instead of getAnnotations() if the
  flag is true.

- Overhauled Javadoc in AnnotatedElementUtils.

Issue: SPR-11475
Merge changes from sbrannen/SPR-11475

* SPR-11475:
  Favor 'local' annotations over inherited ones
Ensure AnnotationUtils is compatible with Java 6

The previous commit introduced a dependency on
Class.getDeclaredAnnotation() which is a Java 8 API.

This commit refactors AnnotationUtils.findAnnotation(Class, Class, Set)
to use Class.getAnnotation() in conjunction with
isAnnotationDeclaredLocally() in order to achieve the same desired
behavior.

Issue: SPR-11475
Update documentation with coding guidelines
This commit:
* adds a reference to the Spring Code Style wiki page in the main
CONTRIBUTING document
* updates the link to the Spring team in README
* adds a note regarding Intellij IDEA 13 issues
Support String contentType headers in spring-messaging

After this change DefaultContentTypeResolver supports String-based
"contentType" header values in addition to MimeType-based.

Issue: SPR-11461
Add strictContentTypeMatching converter option

AbstractMessageConverter now supports a strictContentTypeMatching mode
in which the content type of a message must be resolved to a (non-null)
value that matches one of the configured supported MIME types in order
for the converter to be used.

Issue: SPR-11463
Add getMatchingPatterns method to Patterns condition

Issue: SPR-11484
Add default ContentTypeResolver initialization

Previously AbstractMessageConverter did not have a ContentTypeResolver
configured by default. However the Java config and XML namespace in
spring-messaging and spring-websocket always configured one.

This change ensures every AbstractMessageConverter is configured with an
instance of DefaultContentTypeResolver by default. This makes sense since
all the resolver does is make an attempt to find a content type to use
for matching. If it can't it returns null and it's up to the converter
to decide whether it can convert or not.

Issue: SPR-11462
Remove ContentTypeResolver from composite converter

Before this change CompositeMessageConverter had a ContentTypeResolver
field that was in turn set on all contained converters.

After this change that field is removed and effectively
CompositeMessageConverter is a simple container of other converters.
Each converter in turn must have been configured with a
ContentTypeResolver.

Doing so means it is less likely to have unexpected consequences when
configuring converters, the ContentTypeResolver set in the composite
converter overriding the one configured in a contained converter.

Also commit 676ce6 added default ContentTypeResolver initialization
to AbstractMessageConverter, which ensures that converters are still
straight forward to configure.

Issue: SPR-11462