This PR changes the order of the BootstrapConfigFileApplicationListener to make sure that the BootstrapConfigFileApplicationListener always is executed after the ConfigDataEnvironmentPostProcessor.

The reason
The BootstrapConfigFileApplicationListener relies on the Environment.activeProfiles to have been set correctly, like for instance with the SpringApplication.additionalProfiles. The environment post processor responsible for setting the Environment.activeProfiles correctly (e.g. by adding the SpringApplication.additionalProfiles) is the org.springframework.boot.context.config.ConfigDataEnvironmentPostProcessor. If it runs before the BootstrapConfigFileApplicationListener then everything works correctly. However both the BootstrapConfigFileApplicationListener and the ConfigDataEnvironmentPostProcessor have the exact same order so there is no guarantee in which order they run, meaning that it can also happen that BootstrapConfigFileApplicationListener is executed before the ConfigDataEnvironmentPostProcessor, and in that case the Environment.activeProfiles are not set correctly.

What happens if the two listeners are executed in the wrong order
If the listeners are executed in the wrong order, the Environment.activeProfiles will not have all profiles when the org.springframework.cloud.bootstrap.BootstrapConfigFileApplicationListener is executed. If there are application-<profile>.yml files for those missing profiles, it then does not create the applicationConfig property sources for those configuration files.

For example, I start up the application and provide the production profile as an additionalProfile (for instance via SpringApplicationBuilder.additionalProfile()), and I have a application.yml and application-production.yml on the classpath. If I then look at the property sources, I expect to see the following property source ordering (I left out the unrelated property sources):

• Config resource 'class path resource [application-production.yml]' via location 'optional:classpath:/'
• Config resource 'class path resource [application.yml]' via location 'optional:classpath:/'
• applicationConfig: [classpath:/application-production.yml]
• applicationConfig: [classpath:/application.yml]

However what I sometimes get is:

• applicationConfig: [classpath:/application.yml]
• Config resource 'class path resource [application-production.yml]' via location 'optional:classpath:/'
• Config resource 'class path resource [application.yml]' via location 'optional:classpath:/'

So you can see that the application.yml now has the highest order, and the applicationConfig: [classpath:/application-production.yml] property source is missing. This means the wrong property values will be returned for the properties defined in application-production.yml.

Side question:
I wonder why the BootstrapConfigFileApplicationListener is even needed to create these property sources, as what I can see is that Spring Boot itself also creates the property sources for these files. So now there are always two property sources for every configuration file.