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. 
we can certainly define some sanity rules for not allowing bad rules to enter the set of valid SPs.  Retro-actively invalidating the approval rule based on a future processing glitch seems like it could be used maliciously.  I think instead, blocking the transaction seeking approval is safer as an equivalent transaction could be re-issued after approval rules are fixed and updated and nobody will lose anything but time.  I suppose the catch-22 is when the approval rule for updating the approval rules is the one in question.