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.

Balances are owned directly by addresses. Addresses may be contained in wallets, but that's an application-level construct beyond the scope of the spec.

How about including an optional destination address for the generated coins? That would save tx fees and time.