Move away from spring.factories for auto-configuration imports

[philwebb]

Using spring.factories to find auto-configuration classes is causing problems with our native work. We initially used it because the code was already available, but we want to offer an alternative in 2.7 and stop using spring.factories for auto-configuration in 3.0.

The following required tasks have been identified:

• Design and document a file format that can replace spring.factories for auto-configuration.
• Update the existing import to use both spring.factories and the new entries.
• Introduce a new @AutoConfiguration annotation which is meta-annotated with @Configuration. The new annotation will default proxyBeanMethods to false.
• Document the changes in the reference docs and provide a wiki migration guide
• Update documentation tooling in buildSrc to read the new file
• Check with existing IDE and tool vendors to ensure the new format doesn't cause issues

The following nice-to-have tasks have been identified:

• Develop a migration tool to convert our existing codebase (a tool will be valuable for other project, but we might also be able to use sed)
• Update our annotation processor so the the new auto-configuration file can be auto-generated

We will need to retain spring.factories support for the life of 2.x because Spring Cloud will not be able to migrate to a new system (since it supports 2.6)

[wilkinsona]

Due to @ImportAutoConfiguration support being implemented as a sub-class of AutoConfigurationImportSelector, I think we'll have to tackle it at the same time as working on this. I imagine we'll end up with another file for ImportAutoConfiguration classes. It can use the same format as the new file for AutoConfiguration.

[mhalbritter]

Closed in favour of:

• Introduce @AutoConfiguration #29870
• Migrate auto-configurations to @AutoConfiguration #29871
• Move away from spring.factories for auto-configurations #29872
• Move our auto-configurations from spring.factories to new file #29873