Add @InjectSpy.delegate to evade errors with default methods in intermediate spring-data repo interfaces

[famod]

Evades:

org.mockito.exceptions.base.MockitoException: 
Cannot call abstract real method on java object!
Calling real methods is only possible when mocking non abstract method.
  //correct example:
  when(mockOfConcreteClass.nonAbstractMethod()).thenCallRealMethod();
	at io.quarkus.it.spring.data.jpa.IntermediateRepository.findMandatoryById(IntermediateRepository.java:15)

It can also help with other cases, see https://javadoc.io/doc/org.mockito/mockito-core/latest/org/mockito/Mockito.html#delegating_call_to_real_instance

For this specific case of spring repos, I can't help but think that there might be another solution on class generation level, but I'm lacking the time to dig deeper.
If I create a dummy impl of a repo class, trying to mimic what's happening in ArC, then mockito has no issue with calling a default method in an intermediate interface of that repo. So something might be incompatible here (between mockito/bytebuddy and quarkus/arc)...
I can provide that small playground project if required.

I hope the test class I added is sufficient to play around with. The crucial thing is that PostRepository implements https://github.com/quarkusio/quarkus/blob/main/integration-tests/spring-data-jpa/src/main/java/io/quarkus/it/spring/data/jpa/IntermediateRepository.java

I can't prove it, but I guess that issue could surface for other, non-spring-repo beans as well.

[famod]

Also /cc @mkouba @manovotn, maybe that rings a bell for you.

[famod]

It can be considered a small new feature, but it's "fixing" an annoying issue I have, so I'd like to have it backported. YMMV!
It's only an opt in anyway, so the risk of breaking something is tiny.

[geoand]

Thanks!