Improvements to runtime annotation processors

[dstepanov]

Revisited interfaces to process annotated beans / methods:

• ExecutableMethodProcessor should only be used for executable methods annotated for processing at startup
• Added precalculated list of methods for processing
• Better generics for BeanDefinitionProcessor
• @Parallel no longer supported for parallel processing of ExecutableMethodProcessor
• Scheduled implementation is better without parallel processing

Before this changes getting ExecutableMethodProcessor for startup processing will trigger the search for all the beans annotated with that annotation - unnesessary overhead.

This will require some of our modules (variations of messaging) to migrate to BeanDefinitionProcessor

[graemerocher]

Given the disruption this is likely to cause we need to think whether the change is worth it. Can you clarify what quality of live improvements will come out of merging the PR? Thanks

[dstepanov]

The main problem is that now ExecutableMethodProcessor is used in two completely different scenarios:

• Process executable methods annotated with processed-at-startup - beans for it are marked at the compilation time and indexed
• Process all the methods of beans that are annotated with some annotation - this requires to interate all the beans of the context

The second scenario is exactly what is BeanDefinitionProcessor intended for.

Because we cannot tell which scenario is required we endup invoking both sometimes:
Before this changes when we resolve ExecutableMethodProcessor for Scheduled which is defined as to be processed at the startup we endup triggering scanning for all the beans that are annotated with @Scheduled in AnnotationProcessorListener before the processer is retrived.
Essentially we cannot tell in AnnotationProcessorListener if the processor being initialized is intended for processed-at-startup methods or all the beans with the annotation on it.

[dstepanov]

Restored the previous behaviour with a warning at runtime.