fixes gh-111

fixes gh-108

Overrides Spring Boot's FreeMarkerAutoConfiguration to prefer using a
SpringTemplateLoader instead of the file system. This corrects an issue
where Spring Boot may use an empty 'templates' file resource to resolve
templates instead of the packaged Hystrix classpath templates.

When creating a new project with Spring initializer, an empty
'templates' resource directory is automatically added to the new
project, causing a scenario where this issue may occur.

The Zuul filter registry has to be cleareed (including a cache in
a private field in FilterLoader, yuck).

With this change users can elect not to install the proxy features
but still have a Zuul server with @Beans of type ZuulFilter added
automatically.

Fixes gh-104

 fixes gh-105

fixes gh-76

fixes gh-98

Ribbon and simple host reverse proxy now share quite a lot of
code (everything to do with headers).

Fixes gh-103

Fixes gh-103

removed circular dependency between EurekaClientAutoConfiguration and EurekaDiscoveryClientConfiguration that caused DiscoveryClientConfigServiceBootstrapConfiguration to fail.

fixes gh-99

If user adds auth.route.<service>.scheme: passthru then instead
of adding the bearer token the filter will not do anything
(and the normal authorization header will be passed through
to the backend)

See gh-19

See gh-51

basePath should always be /contextPath/servletPath/ (the last slash being the location of the eureka dashboard)

fixes gh-101

fixes gh-100

Without this change the health status is always UNKNOWN because it
never finds the servo metrics for the health indicator. It's also
a general spruce up of the servo and eureka metrics and health
infrastructure which was looking a little more complicated than
it needed to be (no need for a separate MetricReader).

To avoid possible NPE when the registry is used before it is initialized.

Fixes gh-97

Conflicts:
	spring-cloud-netflix-core/src/test/java/org/springframework/cloud/netflix/feign/SpringDecoderTests.java

Using Spring as an object factory to control the lifecycle of ribbon clients.
So far we have a single, parameterized configuration class for all clients, but
can be extended to allow user to supply additional configuration. The current
model for user extensions is

@EnableRibbonClient(@RibbonClient(name = "foo", configuration = FooConfiguration.class))
public class MainConfiguration {
    ...
}

So in this example, MainConfiguration is part of the "main" application context
and FooConfiguration is used to create the Ribbon client and load balancer for
the "foo" service.

Document FeignClient