INT-3114 Call MessageHandlers Directly

Invoke ARPMH Directly (SA, Splitter etc)

If a bean referenced by a service activator etc, is already an ARPMH,
then wire it directly into the endpoint rather than wrapping it in a
MethodInvoking Handler.

Disallow the same bean being used in this way in multiple endpoints.
It would cause rewiring of outputChannel etc.
Detect such use and suggest using prototype scope.

Previously, an ARPMH used in a MethodInvokingHandler didn't work
in some cases, because the "inner" ARPMH had no output-channel
and the outer ARPMH (e.g. transformer) wouldn't get a reply and
would complain if requiresReply is set.

The general solution is to detect the ARPMH targetObject in
AbstractStandardMessageHandlerFactoryBean, invoke canBeUsedDirect()
to allow the subclass to vote - specifically it will be allowed
if the type is not also a special type understood by the subclass
and no endpoint-specific attributes are set.

To this end, remove a few default attributes from the schema to
enable detection of explicit setting of these attributes.

If these conditions pass and the method is handleRequest (either
explicitly or by omission) then wire it in and invoke the
subclass to post process the handler (set attributes).

Restructure this post processing in each subclass so that it can be invoked in
this way, or directly by the subclass when it makes a custom
handler.

Polishing - PR Comments

Mainly a little refactoring in the RouterFactoryBean to allow
the parameter in canBeUsedDirect() to be an ARPMH instead of
Object.

Plus a couple more minor changes.
INT-1639: Add <spel-function> support

* add `<spel-function>` XSD element
* add `SpelFunctionParser`
* add `SpelFunctionRegistrar` to avoid introducing some confused 'Method'-bean
* add `SpelFunctionRegistrar` collaboration with `IntegrationEvaluationContextFactoryBean`
* some refactoring for `IntegrationEvaluationContextFactoryBean`
* polishing some failed tests after this change

JIRA: https://jira.springsource.org/browse/INT-1639

INT-1639: SpelFunctionParser use BeanClassLoader

INT-1639: Inherit 'functions' from parent AC

INT-1639: Document the <spel-function>

INT-1639: 'NoSuchBeanDefinitionException' fix

Polishing
INT-3122 Return String Properties as String

Make converted object toString() behave as expected
INT-2312: HTTP RequestMapping support

The general idea to use Spring-MVC as much as possible.

* introduce `RequestMapping`, `IntegrationRequestMappingHandlerMapping`
* introduce XSD nested element `<request-mapping>` for HTTP Inbound Endpoints
* introduce `inboundCommonAttributes` XSD attributeGroup for HTTP Inbound Endpoints
* introduce `IntegrationNamespaceUtils#createExpressionDefIfAttributeDefined` & `IntegrationNamespaceUtils#createDirectChannel`
* remove deprecated `name` attribute
* remove `UriPathHandlerMapping` as superseded by `IntegrationRequestMappingHandlerMapping`

JIRA: https://jira.springsource.org/browse/INT-2312, https://jira.springsource.org/browse/INT-2619
INT-2528: Remove deprecations in HTTP module

JIRA: https://jira.springsource.org/browse/INT-2528
INT-2312: Doc for `<request-mapping>`

* Add description to Reference Manual about `<request-mapping>`
* Additional doc polishing
* Add additional test for `<request-mapping>`
* Polishing according PR's comments
INT-2312: 'What's new' and http doc polishing
INT-2312: Add Jackson 2 support for HTTP-inbound
INT-2312: Rebase polishing
INT-2312: Review & email discussion polishing

* Make `RequestMapping` public
* Introduce `HttpContextUtils` and move `HANDLER_MAPPING_BEAN_NAME` to it
* Revert and deprecate public API
* Improve JavaDocs
* Improve Reference Manual
* Rework `IntegrationRequestMappingHandlerMapping` according to email discussion
INT-2312: Polishing after rebase