Smart Property Administration

This proposal is for a unified (and backwards compatible) system of Smart Property Administration.  At the moment, we don't have much need for Smart Property Administration as the only post-broadcast action which exists for Smart Properties is the premature close of a crowdsale.   However, with the sister PR #243 we are (potentially) introducing a Smart Property that will have critical post-broadcast actions and as such we need a system to allow Administration to change hands over time and secure itself against threats like compromised private keys.  Without some formal Administration system, even long-running crowdsales run an increasing risk of being compromised.

The system is meant to propose a few starting paradigms: one that provides backwards compatibility so that administration rules can be applied universally and retroactively and another that provides basic distributed administration to provide robustness against attacks which compromise some of the keys.  However, in the future, more paradigms are likely to appear.

There is one legacy "expectation" that (depending on interpretation) is not currently maintained explicitly: the ability to freely transact in a given Smart Property in perpetuity.  It is possible, that the current implicit Administration of an existing Smart Property could surrender said Smart Property to a new Administration that imposes approval rules on simple sends or Dex messages.  In this way, the implied contract of the original SP could be considered broken as tokens would no longer be transferable without approval.  As a hedge against that, it may be necessary to impose implicit limitations on the Administration for existing SPs, particularly that their approval rules for basic trade are immutable regardless of future Administration changes.

Note: while their is mention of "voting" in the proposal, this is not meant to supplant or replace any previously discussed spec changes for conducting votes on the chain.  While this system may be sufficient for such a need with the addition of a manual "call for vote" that contains its own approval rules, its primary focus should remain the Administration of Smart Property. 
I tried to leave the vote strings themselves up to the application level semantics.  If you wanted to go crazy, there could be  a set of votes that represent a scale [disagree(a), mildly disagree(b), indifferent(c), mildly agree(d), agree(e)] and approval rules that use a simple mathematical formula to provide a less binary approval: "a + b * 2 + c * 3 + d * 4 + e * 5 > TALLY * 3 & AGE > 50" or in English "if we mildly agree or better on average after 50 blocks, lets just do it".

While most SPs will probably have a binary view of voting (or trinary if they like abstains), I felt no need to restrict it.