Play's runtime dependency injection support is built on JSR-330, which provides a specification for declaring how
dependencies get wired to components. JSR-330 however does not address how components are provided to or located
by a DI container. Play's API seeks to address this in a DI container agnostic way.

The reason for providing this abstraction is so that Play, the modules it provides, and third party modules can all
express their bindings in a way that is not specific to any one DI container.

Components are bound in the DI container. Each binding is identified by a BindingKey, which is
typically an interface that the component implements, and may be optionally qualified by a JSR-330 qualifier
annotation. A binding key is bound to a BindingTarget, which describes how the implementation
of the interface that the binding key represents is constructed or provided. Bindings may also be scoped using
JSR-330 scope annotations.

A default implementation of HttpFilters that accepts filters as a varargs constructor and exposes them as a
filters sequence.

A default implementation of HttpFilters that accepts filters as a varargs constructor and exposes them as a
filters sequence. This is available for runtime DI users who don't want to do things in configuration using play.filters.enabled, because they need more fine grained control over the injected components.

This trait is primarily used with results and assets that send files,
for users who want to send a file without having to specify an explicit
content type. For example, a user can send a file with ".json":

The application secret. Must be set. A value of "changeme" will cause the application to fail to start in
production.

With the Play secret we want to:

1. Encourage the practice of *not* using the same secret in dev and prod.
2. Make it obvious that the secret should be changed.
3. Ensure that in dev mode, the secret stays stable across restarts.
4. Ensure that in dev mode, sessions do not interfere with other applications that may be or have been running
on localhost. Eg, if I start Play app 1, and it stores a PLAY_SESSION cookie for localhost:9000, then I stop
it, and start Play app 2, when it reads the PLAY_SESSION cookie for localhost:9000, it should not see the
session set by Play app 1. This can be achieved by using different secrets for the two, since if they are
different, they will simply ignore the session cookie set by the other.

To achieve 1 and 2, we will, in Activator templates, set the default secret to be "changeme". This should make
it obvious that the secret needs to be changed and discourage using the same secret in dev and prod.

For safety, if the secret is not set, or if it's changeme, and we are in prod mode, then we will fail fatally.
This will further enforce both 1 and 2.

To achieve 3, if in dev or test mode, if the secret is either changeme or not set, we will generate a secret
based on the location of application.conf. This should be stable across restarts for a given application.

To achieve 4, using the location of application.conf to generate the secret should ensure this.

Play secret is checked for a minimum length in production:

1. If the key is fifteen characters or fewer, a warning will be logged.
2. If the key is eight characters or fewer, then an error is thrown and the configuration is invalid.