ChannelAdapterParserTests - Increase Receive Times

Fix occasional CI build plan failures.
Add BF Required to Test Builds

Previously, the environment variable that ensures all message creators have
a `BeanFactory` required setting the `SI_FATAL_WHEN_NO_BEANFACTORY` environment
variable to `true`.

Add this variable to `build.gradle`, enforcing the test for all builds.
INT-3565 ClassCastException with Proxy and DEBUG

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

Cast to `IntegrationObjectSupport` fails if the handler is
already proxied in `AbstractSimpleMessageHandlerFactoryBean`.

INT-3565 Polishing

- Fix test.
- enhance test to show that directly bound message handler beans are not advised if already proxied.
INT-3564 Update Javadoc URLs to spring.io

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

INT-3564 Update Javadoc Stylesheet for JDK8
INT-3560: Fix DelayHandler for double emitting

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

`AbstractApplicationContext` has the code:

````java
getLifecycleProcessor().onRefresh();

// Publish the final event.
publishEvent(new ContextRefreshedEvent(this));
````

So, some `Lifecycle`s (e.g. `InboundChannelAdapter`) can emit `Message<?>` and send to the `DelayHandler` before the `ContextRefreshedEvent`.
In this case `DelayHandler` `delays` the `Message<?>` and store it to the `MessageStore`.
When `ContextRefreshedEvent` is happened the `DelayHandler` reschedules all stored `Message<?>` and our 'early' `Message<?>` may be scheduled twice.

Fix an issue with an internal `Map<UUID, ScheduledFuture<?>> delayTasks` for each delayed `Message<?>`.
Remove the `ScheduledFuture<?>` for the `Message<?>` on release.
`cancel(true)` and `clear` all `delayTasks` on the `reschedulePersistedMessages()`.

**Cherry-pick to 4.0.x & 3.0.x**
INT-3560: Use iterator instead of raw cycle

To avoid `ConcurrentModificationException` and to be sure that all fresh schedules will be clear too
INT-3560: Rework `Map<UUID, ScheduledFuture<?>>` to `Queue<UUID>`

* Add `synchronized` to the `reschedulePersistedMessages()`
* Add check for delayed messages from `reschedulePersistedMessages()` to avoid reschedule for messages which already are in progress
INT-3560: Change `Queue` to `newSetFromMap`

Increase receive timeout for messages for `GroovyControlBusIntegrationTests`
INT-3560: Back to the `Map<UUID, ScheduledFuture<?>>`

From one side it is abnormal to send the same `Message<?>` to the `DelayHandler` (as well as to any other component),
it doesn't hart to use `this.delayTasks.put(message.getHeaders().getId(), schedule);` from `releaseMessageAfterDelay`.

From other side we can't determine the state of `ScheduledFuture` after `scheduler.destroy()` (see `GroovyControlBusIntegrationTests`).
The last one does `Thread.interrupt()`, but the `ScheduledFuture`'s state isn't `done`, so we can't skip tasks from `reschedulePersistedMessages`.

From the third side, the `reschedulePersistedMessages` calculates correct actual time for the delay, therefore even if we cancel the current active
task, the new one will be done after correct, message related `delay`.
INT-3560: Change logic to check removal of message from the `MessageGroup`

Get rid of the horror around `Future.cancel()` and `Map.remove()` concern