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. 
unfortunately, I don't see a way around it without breaking fungibility of tokens.  If I vote with my token then pass it to an address which already has tokens and subsequently passes *a* token along, was it the vote-spent token or a non-vote-spent-token that the second address sent.  Perhaps the intent was to pass a vote to someone, or not.  I'm not sure how the protocol can know that without marking the tokens and suffering the UI consequences of differentiating these things.  

We can discuss imposing a maximum age for any vote.  That would limit the time frame where these would need to be cached.