Manually issued Smart Property Tokens

This is a proposed addition to the spec to cover Smart Properties whose tokens are perpetually being created and destroyed to fulfill some application level purpose.  For these properties, the protocol is only used to issue, transact and burn tokens.  All logic concerning when the actions that affect the token pool are appropriate is left up to the discretion of address that broadcast the original smart property definition.  

There are a few obvious use cases at this time:
1. Grants/Revocations of tokens based things the protocol can not verify directly (non-digital asset trades, loyalty and rewards programs)
2. Grants/Revocations of tokens which are authoritatively controlled by a central body (eg private/public equity stock)

Most notably is the project that @CraigSellars is involved in which requires the ability to grant and revoke tokens at will.

Some Notes:
* Grants/Revokes include memo field meant to allow the application/human level logic that drives these protocl messages a black space to put data in for itself.  The protocol does nothing but store this information under the assumption that it is application/human relevant.
* There was some discussion with @marv-engine on whether a (proposed)TX-55 should be a combo "Grant/Send" such that the new tokens are sent to the address that is the destination for the master protocol transaction rather than the wallet that broadcasts the SP transactions.  For now, it is just a "Grant" and the newly granted tokens must be sent explicitly with a simple send.  Certainly willing to entertain the other way.

I am fine with both making this a fixed size optional field (my suggestion would be 20 bytes).  I am also fine with removing all the metadata save for this optional memo/key that can be used to ID related metadata hosted as a signed blob on a 3rd party service.  

My only major concern with it, is the inconsistency with the rest of the smart property issuance transactions.  I think my hesitation is that we could have a separate PR which ups the transaction versions of all existing SP issuance and removes metadata  that would achieve the same effect and keep consistency.