INT-3539: Fix `ChannelSecurityInterceptorBPP`

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

Previously the `ChannelSecurityInterceptorBeanPostProcessor` eagerly loaded all beans from its `afterPropertiesSet`
to retrieve the `ChannelSecurityInterceptor`s. According to the `BeanPostProcessor` nature the `afterPropertiesSet` hook isn't legitimate.
It may cause some bad side-effects for other beans, which might not been initialized yet.

Rework `ChannelSecurityInterceptorBeanPostProcessor` to accept `Collection<ChannelSecurityInterceptor>` in the ctor.
Rework `SecurityIntegrationConfigurationInitializer` to iterate over `BeanDefinition`s to determine those of them, which
are `ChannelSecurityInterceptor` or `ChannelSecurityInterceptorFactoryBean`.

**Cherry-pick to 4.0.x**
INT-3543: Remove `context.close()` from tests

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

Quoting Sam Brannen:

> However, one should *never* programmatically close the injected application context in a test,
since the Spring TestContext Framework caches all contexts across the entire JVM process.
If you need to close a context after a test method or test class for some reason,
the only supported and reliable mechanism is `@DirtiesContext`.

**Cherry-pick to 4.0.x**
INT-3545: Don't AutoStart HeaderChannelRegistry

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

Previously, the `DefaultHeaderChannelRegistry` was auto-started.
This caused the reaper to run and eventually start all the
`taskScheduler` threads, even if the registry was not being used.

- Defer the `start()` until the first channel is stored.
- Do not start the reaper if the bean has been explicitly stopped.
- Deprecate the implementation of `SmartLifecycle`.

Conflicts:
	spring-integration-core/src/main/java/org/springframework/integration/channel/DefaultHeaderChannelRegistry.java

Resolved.

__cherry-pick to 3.0.x__