Affected contract methods:
 - newaccount
 - updateauth
 - deleteauth
 - linkauth
 - unlinkauth

Also, blockchain initialization (the genesis block) behaves like it is
applying a block, even though the genesis block isn't really a block.

We now enforce a recursion depth limit for authority checks. If the
limit is hit, it silently rejects the authority.

Previously, validate_referenced_accounts was called during transaction
application; however, account creation is one of those changes that
doesn't really take effect until the end of the block, so we want to
validate the referenced accounts for all transactions at the beginning
of the block so that if trx A creates account joe, then trx B references
joe, that reference will fail if A and B are in the same block. We also
call it during push_transaction, as we do want to check it for pending
transactions that aren't in a block yet.

I want two things from AuthorityChecker that it wasn't doing yet:
1. I want it to track which of the provided keys were used, so I can
reject transactions which bear more signatures than are necessary
2. To sign a transaction with no unnecessary keys, I want it to support
taking a list of available public keys and an authority, then telling me
which of those keys I should use to fully satisfy the authority, without
having any unnecessary keys

As an added bonus, having both of these operations handled by
AuthorityChecker means that determining the set of keys needed to sign a
transaction, and determining whether a transaction is properly signed,
use the same code. :D

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

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.

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

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

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.

changed the output of the schedulers to be just pending_transactions as those are tagged unions of pointers making them small and easily copyable without needing the additional indirection
implemented basic test cases to stochastically verify that order of transaction delivery does not affect schedulability

NB: we do not have the facilities to create/process these yet but they can be scheduled
scheduling is generated/signed agnostic though the block format still segregates them
chain_controllers _db now has indices for generated transactions.
tests using all signed transactions for now.

closes #139

add basic tests for scheduler

Remove the changes around moving authorizations from Message to
Transaction, as we decided this is not the best way to go. See details
at https://github.com/EOSIO/eos/issues/2#issuecomment-318755302

As of now, almost all the ingredients are in place for authorizing
transactions. We check that the transaction bears signatures sufficient to
satisfy its declared authorizations, and as we execute the transaction,
we ensure that the declared authorizations are sufficient to satisfy the
authorizations required by executing the message handlers, and we ensure
that all of the transaction's declared authorizations were used.

What's not done:
 - Detecting/rejecting duplicate signatures and unnecessary signatures
 - Choosing the correct permission level when a message handler requires
an authorization

Choosing the correct permission level is the big ticket item. To
implement this, we need to implement a missing chunk of system contract
functionality, specifically around defining links from a user's
permissions tree to contracts and message types.

- added account fetching in CLI
- added currency.abi file describing currency contract's ABI

- todo: some of the test are broken because the tests were malformed in
the first place (missing auths)

Replace hardcoded strings (active/owner) with global constants in config.hpp
Change char* constants to specific types and use N() macro for initialization

fix Name() conversion
names now support any characters and those outside the 32 defined are
treated the same as '.'.

It builds, but the tests are a complete mess.

Also define some types and stuff for #7... Lost in the mix.

All transactions must declare a list of permissions they utilize. The
chain now checks that the signatures are present to satisfy these
permissions, at least theoretically (only partially tested). As the
transaction is evaluated and applied, the message handlers will check
that the required permissions were declared on the transaction.

Also, define the logic to check that an authority is satisfied (only this
part is tested so far)

TODO: Test that transactions are rejected if they do not bear sufficient
signatures
TODO: Make message handlers check the declared permissions are sufficient,
and reject the transaction if they are not.