Establish some written governance

This will need to evolve, this proposal is just a starting point based on history and practical concerns for invested stakeholders.

* For the time being, one of the stated project goals is to _support the fuchsia command specification_. This may change over time, but is a nod to our heritage and acknowledging this stakeholder helps us to make shared decisions. It's important to note that the Fuchsia command spec is not immovable, but it has its own governance model.
* We can support non-conflicting features beyond the aforementioned specification, and the library can enable users to write code that violates the aforementioned specification.
* We want to constrain the feature set in the library such that we maintain sight on several key goals:
- small object code
- low cost of ownership implementation
- a balanced simple and easy to use public api surface

We should identify some key stakeholders to take part in decision making with regard to the above, and at a later time establish how that group membership evolves over time. The first implementation of the group will be discretionary.

Practical matters:

* There are a number of issues in the tracker, both open and closed the implementations of which have as yet been avoided due to apparent conflicts with the fuchsia command specification. We would like to respond to these thoughtfully, so the goal is to enable a mechanism by which we can make a project-local decision about which to accept and which to reject, while being considerate as discussed above. For now we'll label those issues as specification change issues, so that we can collate them for focused discussion at a dedicated time.
* Where applicable we will take back some of the suggestions to Fuchsia API council as change proposals for the fuchsia specification, as minimizing the deviation between available features in this library, and the specification to which the (current) largest user group is useful for both sides, as well as outside users who aren't clear on the relationship between the two. I'll take ownership of executing this process, but I'll also make sure to coordinate here so that all voices are heard - the process will be open.
* Some decisions have already been made by maintainers / stakeholders, but are not yet documented (particular those where the decision was not to support something). We will start to respond to issues requesting such features by adding documentation that explains the motivations behind the choice, even if that choice is just arbitrary. Requests to revisit those decisions will remain open, but the requester should bring new use cases / examples / motivations to the discussion.