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.

Fixed size? I actually think the statement was meant as "if a memo field is available in this transaction, then it should be available in other transactions as well" + "memo shouldn't be stored on the blockchain".

Other text fields allow a length of 255 byte, so I would stick to this number, but since the field is at the end of the transaction, (also in general) one could easily add more text behind without invalidating the transaction. Though this wouldn't be parsed and shown by clients which honor the protocol.