Moved executor null check to AsyncExecutionInterceptor, allowing AbstractAsyncExecutionAspect to fall back to sync execution (as in 3.2.1)

Issue: SPR-10636

Issue: SPR-10130

Also optimized AsyncExecutionAspectSupport's Executor-per-Method caching to use a ConcurrentHashMap.

Issue: SPR-10274

This reverts commit 45fa5082, reversing
changes made to a312d900.

Issue: SPR-10130

 - Support external Javadoc links using Gradle's javadoc.options.links

 - Fix all other Javadoc warnings, such as typos, references to
   non-existent (or no longer existent) types and members, etc,
   including changes related to the Quartz 2.0 upgrade (SPR-8275) and
   adding the HTTP PATCH method (SPR-7985).

 - Suppress all output for project-level `javadoc` tasks in order to
   hide false-negative warnings about cross-module @see and @link
   references (e.g. spring-core having a @see reference to spring-web).
   Use the `--info` (-i) flag to gradle at any time to see project-level
   javadoc warnings without running the entire `api` task. e.g.
   `gradle :spring-core:javadoc -i`

 - Favor root project level `api` task for detection of legitimate
   Javadoc warnings. There are now zero Javadoc warnings across the
   entirety of spring-framework. Goal: keep it that way.

 - Remove all @link and @see references to types and members that exist
   only in Servlet <= 2.5 and Hibernate <= 4.0, favoring 3.0+ and 4.0+
   respectively. This is necessary because only one version of each of
   these dependencies can be present on the global `api` javadoc task's
   classpath. To that end, the `api` task classpath has now been
   customized to ensure that the Servlet 3 API and Hibernate Core 4 jars
   have precedence.

 - SPR-8896 replaced our dependency on aspectjrt with a dependency on
   aspectjweaver, which is fine from a POM point of view, but causes
   a spurious warning to be emitted from the ant iajc task that it
   "cannot find aspectjrt on the classpath" - even though aspectjweaver
   is perfectly sufficient. In the name of keeping the console quiet, a
   new `rt` configuration has been added, and aspectjrt added as a
   dependency to it. In turn, configurations.rt.asPath is appended to
   the iajc classpath during both compileJava and compileTestJava for
   spring-aspects.

Issue: SPR-10078, SPR-8275, SPR-7985, SPR-8896

Issue: SPR-9652

@Async executor qualification has been backported to 3.1.2. This commit
updates all @since tags appropriately, as well as carrying over the
changes backported to the spring-task-3.1 schema.

Issue: SPR-6847, SPR-9443

Commit 096693c4 refactored and
deprecated TransactionAspectUtils, moving its #qualifiedBeanOfType
and related methods into BeanFactoryUtils. This created a package cycle
between beans.factory and beans.factory.annotation due to use of the
beans.factory.annotation.Qualifier annotation in these methods.

This commit breaks the package cycle by introducing
beans.factory.annotation.BeanFactoryAnnotationUtils and moving these
@Qualifier-related methods to it. It is intentionally similar in name
and style to the familiar BeanFactoryUtils class for purposes of
discoverability.

There are no backward-compatibilty concerns associated with this change
as the cycle was introduced, caught and now fixed before a release.

Issue: SPR-6847

Prior to this change, Spring's @Async annotation support was tied to a
single AsyncTaskExecutor bean, meaning that all methods marked with
@Async were forced to use the same executor. This is an undesirable
limitation, given that certain methods may have different priorities,
etc. This leads to the need to (optionally) qualify which executor
should handle each method.

This is similar to the way that Spring's @Transactional annotation was
originally tied to a single PlatformTransactionManager, but in Spring
3.0 was enhanced to allow for a qualifier via the #value attribute, e.g.

  @Transactional("ptm1")
  public void m() { ... }

where "ptm1" is either the name of a PlatformTransactionManager bean or
a qualifier value associated with a PlatformTransactionManager bean,
e.g. via the <qualifier> element in XML or the @Qualifier annotation.

This commit introduces the same approach to @Async and its relationship
to underlying executor beans. As always, the following syntax remains
supported

  @Async
  public void m() { ... }

indicating that calls to #m will be delegated to the "default" executor,
i.e. the executor provided to

  <task:annotation-driven executor="..."/>

or the executor specified when authoring a @Configuration class that
implements AsyncConfigurer and its #getAsyncExecutor method.

However, it now also possible to qualify which executor should be used
on a method-by-method basis, e.g.

  @Async("e1")
  public void m() { ... }

indicating that calls to #m will be delegated to the executor bean
named or otherwise qualified as "e1". Unlike the default executor
which is specified up front at configuration time as described above,
the "e1" executor bean is looked up within the container on the first
execution of #m and then cached in association with that method for the
lifetime of the container.

Class-level use of Async#value behaves as expected, indicating that all
methods within the annotated class should be executed with the named
executor. In the case of both method- and class-level annotations, any
method-level #value overrides any class level #value.

This commit introduces the following major changes:

 - Add @Async#value attribute for executor qualification

 - Introduce AsyncExecutionAspectSupport as a common base class for
   both MethodInterceptor- and AspectJ-based async aspects. This base
   class provides common structure for specifying the default executor
   (#setExecutor) as well as logic for determining (and caching) which
   executor should execute a given method (#determineAsyncExecutor) and
   an abstract method to allow subclasses to provide specific strategies
   for executor qualification (#getExecutorQualifier).

 - Introduce AnnotationAsyncExecutionInterceptor as a specialization of
   the existing AsyncExecutionInterceptor to allow for introspection of
   the @Async annotation and its #value attribute for a given method.
   Note that this new subclass was necessary for packaging reasons -
   the original AsyncExecutionInterceptor lives in
   org.springframework.aop and therefore does not have visibility to
   the @Async annotation in org.springframework.scheduling.annotation.
   This new subclass replaces usage of AsyncExecutionInterceptor
   throughout the framework, though the latter remains usable and
   undeprecated for compatibility with any existing third-party
   extensions.

 - Add documentation to spring-task-3.2.xsd and reference manual
   explaining @Async executor qualification

 - Add tests covering all new functionality

Note that the public API of all affected components remains backward-
compatible.

Issue: SPR-6847