Refactor SpringApplication#setupProfiles and #addPropertySources methods

Here's one to consider prior to GA, especially given that it would be a breaking API change.

Regarding [SpringApplication#setupProfiles](https://github.com/spring-projects/spring-boot/blob/cd3d4b485d0c7cd6dbaaec7c17b4cbf90863762e/spring-boot/src/main/java/org/springframework/boot/SpringApplication.java#L412):

 - `configureX` vs. `setupX` is more aligned with existing naming conventions throughout the core framework.
 - "setup" is not a verb.
 - Configuring profiles is just one of the things a user could do with the `Environment` they're being handed (manipulating property sources would be another). Thus, `configureEnvironment` is a more accurate name.

As I was writing the above, I just noticed that there is also an [#addPropertySources](https://github.com/spring-projects/spring-boot/blob/cd3d4b485d0c7cd6dbaaec7c17b4cbf90863762e/spring-boot/src/main/java/org/springframework/boot/SpringApplication.java#L385) method that accepts the `Environment` as well as the String[] of args passed to the `#run` method.

How about refactoring this arrangement as follows?

 - Rename `#addPropertySources(Environment, String[])` to `#configurePropertySources(Environment, String[])` ("configure" is better here as well, given that property sources could be removed or reordered, not just "added").
 - Rename `#setupProfiles(Environment)` to `#configureProfiles(Environment, String[])` (accept the String[] of args here too)
 - Add `#configureEnvironment(Environment, String[])` as a template method that delegates to the above two methods in that order.
 - Update [SpringApplication#run](https://github.com/spring-projects/spring-boot/blob/cd3d4b485d0c7cd6dbaaec7c17b4cbf90863762e/spring-boot/src/main/java/org/springframework/boot/SpringApplication.java#L272) to call the new `#configureEnvironment` method instead of calling the former methods individually.
 - Add JavaDoc `@see` references to each method to inform folks of the relationship between them.

I bring all of this up because we're now hooking into `#setupProfiles` in the Sagan application to codify and enforce our profile semantics, and we will be pointing users to it in blog posts and documentation. I was really glad to find this method—it suits our needs perfectly, and I could see using it becoming a best practice for apps that have anything beyond the most trivial profile arrangements.