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.

change "Instead to additional ..." to "Instead two additional ...".

We have to see if the spec or the code assumes there is a non-zero number of tokens for each smart property. I expect not, e.g. a crowdsale creates the smart property but no tokens are issued until the first user sends a payment.