Back port Error Handling fix to v3

Consider back porting #2570 to v3.

The reason for this is because in SCSt v3 a developer was/is able to use @ServiceActivator to configure error handlers to either globally handle errors for all functions or different "binding specific" error handlers. These options acted a bit differently b/c of how they are wired with the spring integration channels under the covers but to the end user they acted as follows:

• Global Error handler is more for notification purposes. You could NOT actually handle the error as the framework would still tell the binder there was an error handling the message even after successful exit of the error handler
• Binding specific error handler is different. With @ServiceActivator you could actually handle the error, exit successfully, and the framework would tell the binder the message was handled.

The purpose of introducing the ability to configure error handlers via configuration was not to change how the framework handles errors in either of these scenarios, but rather to make it easier to wire up the error handlers themselves and remove messaging channel logic from the code. Because of this I would have expected the same runtime functionality. This is what #2570 resolved, but only for SCSt v4. Ideally we can back port that to v3 so developers that can't change to Spring Boot 3, which requires Java 17, can wire up their error handlers via configuration without changing the runtime functionality.

Thanks for the consideration!

@olegz

Start by reading issue #2570 and comparing its error-handling changes with the v3 configuration path and Spring Integration @ServiceActivator behavior. Verify the v3 behavior for global and binding-specific handlers, with completion defined by matching the described handling semantics without requiring developers to change their configuration.