See gh-482

This is quite a big step, but I think it helps a lot. Since Spring
Boot always creates an AuthenticationManager if it doesn't find one
already registered, it makes sense to also make it into a @Bean.
Spring Security does not register its AuthenticationManager by
default though, so we have to do that for it if the user has created
one with an @Autowired AuthenticationManagerBuilder, but not registered
it as a @Bean.

Having the @Bean (marked @Primary to prevent issues with @Autowired)
makes it easier to reason about what Spring Boot has done for you, and
easier to default in simple use cases to the boot-created
AuthenticationManager. For example, if I want an OAuth2 Authorization
Server with password grant, it makes total sense for the
AuthenticationManager for users to be the same as the @Primary one.
Now it is easy to set that up (just @Autowire it).

also adds another test.

...bean with no explicit @Bean DispatcherServlet. We still have to check
by bean name (slightly unfortunate, but we need to avoid instantiating
too early) so there's now another magic
bean name for the registration bean ("dispatcherServletRegistration")
that the user has to replace if he wants the registration without
defining a servlet @Bean

Fixes gh-482

The source of the exception is in sun.misc (so hard to track down precisely)
but it's clear that the LaunchedJarURLClassLoader needs to be more
defensive and return null from findResource() if it can't find it.

Fixes gh-486

Fixes gh-481

User can now also switch off and customize the websockets customizer by adding
a bean named "websocketContainerCustomizer".

Fixes gh-479

Fixes gh-476

Makes them a lot more readable IMO, and also enables @Autowiring
from the context into the test case (sweeet). I added @DirtiesContext
to all of them as well to be on the safe side, but possbly that can be
optimized in some way as well.

Allowing use of embededded container in @SpringApplicationConfiguration
tests, e.g.

```
@RunWith(SpringJUnit4ClassRunner.class)
@SpringApplicationConfiguration(classes = Config.class)
@WebAppConfiguration
@IntegrationTest
public class SpringApplicationIntegrationTestTests {

	@Test
	public void nestedConfigClasses() {
		String body = new RestTemplate().getForObject("http://localhost:8080/",
				String.class);
		assertEquals("Hello World", body);
	}

	@Configuration
	@EnableWebMvc
	@RestController
	protected static class Config {

		@Bean
		public DispatcherServlet dispatcherServlet() {
			return new DispatcherServlet();
		}

		@Bean
		public EmbeddedServletContainerFactory embeddedServletContainer() {
			return new TomcatEmbeddedServletContainerFactory();
		}

		@RequestMapping("/")
		public String home() {
			return "Hello World";
		}

	}

}
```

Fixes gh-473

Per discussion: fixes gh-467

Fixes gh-470

We had been making a special case for logback.xml anyway, so
extending that to simply deleting recursively all of
src/main/resources (or equivalent) from target/classes (or
equivalent) seems like it's perfectly justifiable.

Fixes gh-451

The management.contextPath property should now be respected in a
secure application, whether or not the management.port is different.

Added some test cases in the sample to verify.

Fixes gh-469

Boot promotes the use of a templates directory for housing view
templates. Include this directory by default when building a jar file
from a CLI app.

Fixes #455

Fixes gh-463

Explicitly link to install.txt in source repo to avoid issues on projects.spring.io with a broken relative link
... also fix this for rendered markdown on GH itself :-)

Use org.springframework.boot instead of ${project.groupId}
groupId in order to make it easier to use spring-boot-samples
modules as a starting point for new projects.

Fixes gh-447

This turns out to affect JPA, but only because it looks for a URL for the
root of the classpath using ClassLoader.getResource("") which barfs in
an app launched from an executable JAR. It's easy to make a special case
for "" in the class loader, so I went ahead and did that. Possibly need
to think what the implication of getResources("") is as well (not
tested in an app yet).

Fixes gh-420

Fixes gh-441

Profiles set with Environment.setActiveProfiles() (rather than
spring.profiles.active) *before* any config files are processed, are
treated as "additional" (to the ones supplied in spring.profiles.active
from all sources, files and System properties included).

Fixes gh-429

Fixes gh-438

Fixes gh-417

RC4 added a ServletRegistrationBaen for teh DispatcherServlet and we
didn't register a MultipartConfigElement if one was present.

Fixes gh-427

Fixes gh-424