MULE-6825: Make loggin less verbose in CompositeApplicationClassLoader
(cherry picked from commit 5809ba1)
Cleaning code: renaming method params
(cherry picked from commit c9f6e38)
MULE-6816: Shutdown timeout is not respected

One-way scenario:

On this scenario, the shutdown timeout works as expected as the processing is done using an AsyncInterceptingMessageProcessor.
AsyncInterceptingMessageProcessor has a dedicated workManager. That work manager is disposed on the AsyncInterceptingMessageProcessor#stop method. So, that method waits until the work manager is disposed (and the works too).
The work manager uses the shutdown timeout to shutdown itself.

Request-reply scenario:

On this scenario, the shutdown timeout does not work as expected.
Problem is that the message receivers use the connector's work manager. That work manager cannot be disposed as part of the message source stopping phase (because can be shared by receivers).
This causes that the works enqueued or already in process will attempt to continue processing, but they will find that the flow is already stopped.

Fixed adding a work manager wrapper that can be managed as part of the message receiver's lifecycle.
NOTE: with this fix we are not able to stop pending works once the timeout has expired. Some scenarios using mule client will still get this error as mule client uses a different way to send requests.
(cherry picked from commit f97c858)
MULE-6816: Shutdown timeout is not respected

Cleaning pending works on message receiver's dispose
(cherry picked from commit 32b3a54)