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 idetection 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 iin 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
Polishing - PR Comments to-date
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.