Add support for "configuration extensions"

[krancour]

In the back of my head, I want to make alternate implementations of router possible, so all along I've intended to avoid exposing configuration options that are nginx-specific. This is easier said than done because, frankly, even with more generic names, the bulk of the router configuration is nginx-specific. Getting creative in coming up with more generic names for things only ends up obfuscating the function of each option.

To work around this, I propose adding support for implementation-specific "extensions" to the router configuration. So, for instance, anything that is undeniably nginx specific and meaningless in the context of another hypothetical implementation (such as HAProxy), might be moved into an "extensions": { "nginx": { ... } } section of the configuration.

[krancour]

Just capturing some further thoughts on this before I lose them...

It goes without saying that alternative implementations of the router component would naturally support different configuration options that vary with the capabilities, limitations, and native dialect of the underlying tech. Options for Nginx vs HAProxy will be different and there's not much that can be done to smooth that over. But I think that doesn't matter...

The thing that matters is that the "contract" between deis-workflow (or alternative PaaS API/controller) and the router is always honored. When it comes down to it, there are a scant few configuration options that are affected by that and they revolve around the attributes of the AppConfig type.

The bottom line is that I think this issue can probably be adequately resolved through a reorganization of the documentation to separate the contractual / non-negotiable aspects of the configuration from the implementation-specific aspects.

[krancour]

Replaced by #111