Remove the changes around moving authorizations from Message to
Transaction, as we decided this is not the best way to go. See details
at #2 (comment)

1) add default command - help
2) prevent segfault

We now check authorization of transactions when they come in as pending,
and again when we apply them in some block (either when generating the
block or when applying it). When applying the transactions in a block,
we check auth for all transactions in the block prior to processing any.

To check auth, we first scan all of the declared authorizations, and
check that the authorization is sufficient to grant permission for the
given account to execute the given message type (TODO: look up the
actual required permission level rather than just assuming it's
'active'); then, check that the transaction bears signatures to confer
the declared authorization.

Require_authorization is now implemented so as the contract executes and
asserts that a particular account approved the transaction, the chain
asserts that this is so and throws if not.

Also, update the tests, since the auth checks now bring to bear the rule
that an account cannot be used in the same block that creates it. The
tests now comply with this rule.

TODO:
 - Check that all declared authorizations get required by the contract
 - Implement the mapping from user permissions to message types
 - Use mapping of permission to message type in
lookup_minimum_permission

Define the types documented in the issue.

TODO: Implement logic

Add docs on some of the types, register the index, and implement
chain_controller::lookup_minimum_permission.

The name requirepermission was too long, so I renamed it linkauth

Implement the linkauth handler in the system contract

Add an unlinkauth message type which removes a link from a message type
to a required authority

Add a check to the validate function on authority which checks that the
authority can be satisfied, which is to say, that the total of all the
weights meets or exceeds the threshold.

Though not strictly part of issue 123, this is a necessary step in order
to complete #123. Rename UpdatePermission->updateauth and
DeletePermission->deleteauth, and implement them.

At this point, I think #123 is fully implemented and ready for testing.

Add a new testing helper macro, Complex_Authority, to create an
arbitrary Authority inline with a slightly less confusing syntax

Create and smoke test Add_Authority and Delete_Authority test helper
macros

The behavior change is that I am forbidding changing a
permission_object's parent until we come up with a safe way to support
it. The issue is that it's possible to create loops by creating an
object A with an existing parent B, then setting B's parent to A. The
obvious solution is to ensure with every parent change that there is a
path back to the owner authority by following parents, but to do this we
need a tree depth limit. I haven't explored the implications of that, so
I'm just disabling parent changes for the time being. The user can
simply delete the old subtree and create a new one if he wants to move a
subtree from one parent to another.

Otherwise the build fails on my system

Add macros for Link_Authority and Unlink_Authority, write some initial
tests of these operations, and fix a bug (unlinkauth didn't require any
authority)

When rejecting a transaction due to excessive authorizations on a
message, include the authorizations which were not necessary in the
reported error