Polish Servlet async request processing

* Clarify semantics and behavior of AsyncWebRequest methods in most cases
making a best effort and not raising an exception if async processing
has completed for example due to a timeout. The startAsync() method is
still protected with various checks and will raise ISE under a number
of conditions.
* Return 503 (service unavailable) when requests time out.
* Logging improvements.

Issue: SPR-8517
Add ability to handle a timeout to DeferredResult

When a controller returns a DeferredResult, the underlying async
request will eventually time out. Until now the default behavior was
to send a 503 (SERVICE_UNAVAILABLE). However, this is not desirable
in all cases. For example if waiting on an event, a timeout simply
means there is no new information to send.

To handle those cases a DeferredResult now accespts a timeout result
Object in its constructor. If the timeout occurs before the
DeferredResult is set, the timeout result provided to the constructor
is used instead.

Issue: SPR-8617
Fix encoding issues in javadoc

Before this change javadoc in two classes had non-UTF-8 encoded
characters. This caused building Spring API to fail in Java 1.7.

Commit fixes this by replacing wrongly encoded characters with their
UTF-8 equivalents.

Issue: SPR-9097
Merge pull request #35 from sslavic/SPR-9097

* SPR-9097:
  Fix encoding issues in javadoc
Fix javadoc warnings

Before this change there were numerous javadoc warnings being reported
while building Spring framework API.

This commit resolves most of the javadoc warnings, reducing the total
number from 265 to 103.

Issue: SPR-9113
Merge pull request #36 from sslavic/SPR-9113

* SPR-9113:
  Fix javadoc warnings
Convert SpEL plus operands using reg'd converters

Prior to this commit, SpEL's OpPlus ('+' operator) would convert its
left and right operands to String directly via #toString calls.

This change ensures that operand values are delegated to any registered
converters, allowing for customization of the stringified output.

Note that the OpPlus constructor now throws IllegalArgumentException if
zero operands are supplied.

Issue: SPR-8308
Merge pull request #7 from bedla/SPR-8308

* SPR-8308:
  Convert SpEL plus operands using reg'd converters
Fix scoped-proxy memory leak w/ @Resource injection

Prior to this change, request-scoped components having
@Resource-injected dependencies caused a memory leak in
DefaultListableBeanFactory#dependenciesForBeanMap.

Consider the following example:

    @Component
    @Scope(value="request", proxyMode=ScopedProxyMode.TARGET_CLASS)
    public class MyComponent {

        @Resource
        private HttpServletRequest request;

        // ...
    }

The bean name for "MyComponent" will end up being
'scopedTarget.myComponent', which will become a key in
the #dependenciesForBeanMap structure.

On the first request, the injected HttpServletRequest bean will be a
proxy and will internally have a bean name of the form
"$Proxy10@1a3a2a52". This name will be added to the Set value associated
with the 'scopedTarget.myComponent' entry in #dependenciesForBeanMap.

On the second request, the process will repeat, but the injected
HttpServletRequest will be a different proxy instance, thus having a
different identity hex string, e.g. "$Proxy10@5eba06ff". This name will
also be added to the Set value associated with the
'scopedTarget.myComponent' entry in #dependenciesForBeanMap, and this
is the source of the leak: a new entry is added to the set on each
request but should be added only once.

This commit fixes the leak by introducing caching to
CommonAnnotationBeanPostProcessor#ResourceElement similar to that already
present in AutowiredAnnotationBeanPostProcessor#AutowiredFieldElement
and #AutowiredMethodElement. Essentially, each ResourceElement instance
now tracks whether it has been created, caches the ultimate value to be
injected and returns it eagerly if necessary. Besides solving the memory
leak, this has the side effect of avoiding unnecessary proxy creation.

This fix also explains clearly why injection into request-scoped
components using @Autowired never suffered this memory leak: because the
correct caching was already in place. Because @Resource is considerably
less-frequently used than @Autowired, and given that this particular
injection arrangement is relatively infrequent, it becomes
understandable how this bug has been present without being reported
since the introduction of @Resource support in Spring 2.5: developers
were unlikely to encounter it in the first place; and if they did, the
leak was minor enough (adding strings to a Set), that it could
potentially go unnoticed indefinitely depending on request volumes and
available memory.

Issue: SPR-9176
Merge pull request #66 from dridi/SPR-9176

* SPR-9176:
  Fix scoped-proxy memory leak w/ @Resource injection