DOCS: write a bit about approach between declarative control and imperative

[squillace]

Up until now, porter.yaml has increased its functionality and usability by strengthening the declarative functionality and behavior in the mixins and porter itself. We are now getting more questions with more complex bundles about adding various imperative features to the system.

The bias we have in Porter is against imperative, and for now I believe -- issues! -- we should hold the line and assert that for the short term imperative behavior should occur in added scripts and in mixins, as anyone can build and use them.

Assuming we're all good with that approach for now, I'd like to write a little bit about that bias, and make it clear that we aren't opposed to adding them going forward at some point, but are instead thinking about the critical features in the short term.

What do we think about that idea?

[carolynvs]

I think we could pepper the docs with guidance about how porter is a declarative tool, and provide best practices for achieving what they need.

• Add a "Declarative Bundles" page under the Authoring Bundles nav that explains that porter.yaml is declarative, and how that works.
• Add a Best Practice that explains how people can write their scripts or mixins when they need imperative logic.
• Add the explanation about why we approached porter the way we did (if we do feel the need to justify) in the Porter Architecture.

We can cross-link as necessary but otherwise we don't overwhelm people with too much info and can split up targeted advice, 'splaining, and general overview of our declarative nature.