Implement the linkauth handler in the system contract

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

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

Define the types documented in the issue.

TODO: Implement logic

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.

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.

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

It builds, but the tests are a complete mess.

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

I think I've implemented all of it, but it's not tested yet so I'm
leaving the issue open for now.

Initial work on locking EOS, beginning unlock, and claiming unlocked
EOS.

TODO: Actually split the system contract, and define names for the
different parts so we can check that the required notifications are made.
Also, figure out how to write notify handlers for the native contracts,
to handle these critical balance updates in the staking/unstaking of
EOS. See the #warning TODO comments in the commit for context.

Add support for producers specifying their votes on chain configuration
values to CreateProducer and UpdateProducer.

Add more tests around chain configuration, including a failing test case
verifying that the blockchain itself handles configuration updates
correctly. Presently this test fails because the chain does not yet
attempt to keep track of rounds, thus it cannot update the configuration
at the beginning of the round.

Remove chain::Transaction altogether, move its methods to
chain::SignedTransaction, which solely inherits
types::SignedTransaction, which solely inherits types::Transaction.
Aside from having no diamonds, this also eliminates vtables in the
Transaction types, which is necessary in order to store transactions in
the database.

We have a number of types defined in eos::chain like transaction,
message, etc. which parallel autogenerated types in eos::types. They are
identical in storage, but the chain types have various helper methods
which the autogenerated types, of course, lack.

I've unified these by letting the generated classes in types:: store the
data, and having the chain:: types inherit these data stores and add
functionality to them via methods.

This commit adds the BlockchainConfiguration type, which contains the
values to be voted on by producers. It also adds the algorithm to create
a BlockchainConfiguration containing the median values from a vector of
BlockchainConfigurations. Finally, it adds a testcase which verifies that
the median calculation is performed correctly.

Dependencies for code generation were not set up correctly (in fact,
they were cyclic) which meant that code generation never took place
after initially setting up the repo. Now it should run automatically
whenever types.eos or the generator itself changes

- it is now possible to set an Apply Handler that can store/fetch data
- TBD - actually reading the message being passed in and generating
messages

- update fc to use EOS local repository on github
- add type library in to build process