Parent stack behavior is confusing on Update.

[askreet]

In Moonshot 0.7.x, we has parameter files which made it trivial to ignore parent stack options.

Now, we query the parent stacks for outputs in create and update actions. However, consider the following use cases where an application has a configured parent stack in Moonfile.rb:

Development non-standard parent stack.

• Developer launches a stack using a non-standard parent stack, by passing --parent-stack to create.
• Later, the parent stacks are updated with a new Output.
• Developer wants to take advantage of this new Output in their stacks Parameters, so they run moonshot update. However, since there is a default parent stack, the new Output is taken from there and not the original parent stack.

Development-only parent stack.

• Developers launch application stacks against a shared development-only parent stack, but production environments have dedicated parent stacks per environment (e.g. customer deployments).
• When running moonshot update in production, an error is generated saying the default (shared development) parent stack isn't found (because they are in a different AWS account). The result is all production updates require the same --parent-stack option that was originally used, even though no Parameters will be updated.

Proposed solution

The parent_stacks option, which sets the default parent stacks, is used only for create and never for update. Any updates which require pulling in new parent stack Outputs will require an explicit --parent-stack option, or will result in a prompt for the new parameter.

[askreet]

@glennpratt suggested we instead store the parent stack, using a parameter on the CloudFormation stack. For backwards compatibility with 1.x, we should check to see if that parameter exists. If it does, we set it on update/create by mapping --parent-stack into a parameter override. We refuse to change this value if it's already set on update, and we replace the controller config's parent stack default with whatever is set in AWS.

[askreet]

The second issue here can be resolved by the new features in #181. I may bump this back to v1.2.