Orchestration

The intent of this WIP PR is to solicit feedback on the PHP API of Orchestration early and often.

The first set of commits to this PR will be non-functional code samples for Orchestration. The goal of this exercise to design the Orchestration PHP API from the perspective of a developer using this API. Please review these commits as they come in and provide feedback. This will ensure that the feedback is incorporated into future commits.

Once the PHP API is finalized via code samples, the next set of commits to follow will be documentation of the API. Specifically, these will be a Getting Started Guide (similar to https://github.com/ycombinator/php-opencloud/blob/master/docs/userguide/ObjectStore/README.md) and a Complete User Guide (similar to https://github.com/ycombinator/php-opencloud/blob/master/docs/userguide/ObjectStore/USERGUIDE.md). There will be links from the latter to the previously-committed code samples.

Once the documentation commits have been reviewed and finalized, the final set of commits to this PR will be the tests and actual implementation of the API, that is the various classes under the `OpenCloud\Orchestration` namespace.

Once the tests and implementation have been reviewed and finalized, this PR will no longer be WIP. At this point, it may be merged.

To summarize:
* [x] Code samples
* [x] Documentation
* [x] Unit tests and implementation
* [x] Testing code samples against implementation
* [ ] Smoke tests

/cc @gecampbell @jamiehannaford 
I think the question is about how a user will _expect_ to interact with the data provided by this information. Will they insist on having it in a format consistent with how a `Stack` object works (i.e. through getters), or will they be satisfied with a `stdClass` object or simple array. From my perspective, this operation is a dry-run; it shouldn't modify my initial object. Maybe returning a new Stack would suffice?