Prevent early bean initialization with @EnableCaching

Prior to this commmit, any configuration class holding a CacheManager
bean would be eagerly instantiated. This is because the
CacheConfiguration infrastructure requests all beans of type
CacheManager.

This commit defers the resolution of the CacheManager as late
as possible.

Issue: SPR-12336
HibernateJpaSessionFactoryBean is compatible with Hibernate 4.3 as well now

Issue: SPR-12401
Unit tests for java.util.Optional with autowired collections on @Autowired fields/methods and @Bean method parameters

Issue: SPR-9132
Revised scheduling lifecycle integration

ScheduledAnnotationBeanPostProcessor uses getBean(Class) for TaskScheduler/ScheduledExecutorService retrieval, allowing for a scheduler bean to be flagged as primary, and for a TaskScheduler bean to override a ScheduledExecutorService bean.

ContextLifecycleScheduledTaskRegistrar hooks into SmartInitializingSingleton's afterSingletonsInstantiated callback instead of ContextRefreshedEvent, as a natural consequence of SmartInitializingSingleton's introduction in Spring Framework 4.1 GA.
BeanDefinitionValueResolver preserves original String array if possible and resolves nested String arrays as well

Issue: SPR-12391
Add an alwaysInclude property to TilesViewResolver

Issue: SPR-12374
Revised retrieval of cache strategy beans

Issue: SPR-12336
Reduced DefaultJCacheOperationSource's dependency from ApplicationContext to BeanFactory

Issue: SPR-12336
Polishing
DefaultListableBeanFactory efficiently accesses current bean names and exposes them via getBeanNamesIterator()

Issue: SPR-12404
Upgrade to Hibernate 4.3.7 (and Netty 4.0.24)
Polishing
Clean up warnings in spring-websocket
Clean up warnings in spring-jms
MockHttpServletRequestBuilder allows for specifying content type as String value

Issue: SPR-12405
Defensive handling of manually registered singleton names (based on Spring Integration test failure)

Issue: SPR-12404
Test for cyclic type declaration handling in TypeDescriptor

Issue: SPR-9735
(cherry picked from commit 7fa3e65)
Polishing
(cherry picked from commit acefd83)
Explicitly clear manually registered singleton names after destroySingletons call

As indicated by our recent Spring Integration test failure, autowiring attempts after context closing did not fail before. After the introduction of the separately managed manualSingletonNames set, the algorithm could run into a situation where a singleton name is still in the manualSingletonNames set but not in the singletonObjects map anymore. As a remedy, destroySingletons needs to explicitly clear the manualSingletonNames set in order to remove references to non-disposable singleton beans as well (which are otherwise left in the set since individual destroySingleton calls only come in for disposable beans with destroy methods).

Issue: SPR-12404
Fix typo