Handle multiple configurations natively

[lbergnehr]

Is your feature request related to a problem? Please describe.
When operating multiple environments (state stores and secrets stores), it's chore to switch between the different stores, having to manually edit the configuration file in some way.

Describe the solution you'd like
It would be nice if Porter provided some mechanism to easily switch between different configurations. You could have one configuration mapping to one environment and another mapping to another. You could even imagine having a configuration tree where base configuration could be inherited/overridden by more specific configuration.

So that I could do either (simple):

• PORTER_CONFIG_HOME=~/porter/prod porter installation list
  or, more advanced:
• porter config use prod && porter installation list
  or
• porter installation list --configuration=prod.

Describe alternatives you've considered
The simplest solution would be to just provide a way for Porter to know where to look for its configuration. Right now, this is given by the PORTER_HOME variable, but changing this also means changing the mixins and other things already installed. It would be nice if the configuration could be set even finer-grained than the whole Porter home.

A more fully managed solution would be to have Porter manage the different configurations for you, possibly with a new sub-command.

Additional context
We've created wrapper scripts to work around this internally, but they require creating a shim for Porter and copying/linking files when changing "environment" which feels hacky and is error-prone, especially when trying to support different shells.

[kichristensen]

Thanks for the suggestion @lbergnehr, it makes a lot of sense. Will put it on the slate for v1.5.0. Hopefully we can find a good backward compatible way.
I would prefer something similar to the last two suggestions, currently leaning towards the last one, as it aligns with how namespaces are handled in Porter already.

[kichristensen]

When implementing this, we should consider if we want to prepare, implement or close #1077

[lbergnehr]

I would prefer something similar to the last two suggestions, currently leaning towards the last one, as it aligns with how namespaces are handled in Porter already.

As given the ability to specify this as a command line option will automatically make it possible to set a corresponding environment variable to control the option, thus simulating porter config use ... alternative, I think it's the best option given that we will want to keep the scope down.