INT-3820: Fix MethodInvokerHelper for the Proxy

JIRA: https://jira.spring.io/browse/INT-3820

Some Proxy may be based on the specif non-user classes and advised with
the provided end-user interfaces.
The best sample is `@Repository` from Spring Data projects.
In this case the `MessagingMethodInvokerHelper` just missed the user interfaces
to consider for the candidate methods or thrown an `Exception` like `NoSuchMethodError`.

* Add `((Advised) targetObject).getProxiedInterfaces()` for the scanning algorithm
* Move the `UniqueMethodFilter` to the internal `Set<Method>` to allow iteration
and filtering for methods from the `targetClass` as well as from all those user interfaces
* Add Spring JPA repository test-case
* Polishing form some time-weak tests

Revert MessagingMethodInvokerHelper

INT-3820: Simple Proxy Interface Method Matching

No-risk solution for INT-3820.

Instead of considering all interfaces on the proxy, only look at proxy interfaces
for a single matching method name if we find no candidate or fallback methods.

Consider the complete solution for 4.3.

Add `Message<?>` method distinguishing

spring-integration-file/src/main/java/org/springframework/integration/file/filters/AbstractPersistentAcceptOnceFileListFilter.java

@@ -63,7 +63,7 @@ public abstract class AbstractPersistentAcceptOnceFileListFilter<F> extends Abst
 	/**
 	 * Determine whether the metadataStore should be flushed on each update (if {@link Flushable}).
 	 * @param flushOnUpdate true to flush.
-	 * @since 1.4.5
+	 * @since 4.1.5
 	 */
 	public void setFlushOnUpdate(boolean flushOnUpdate) {
 		this.flushOnUpdate = flushOnUpdate;