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.

- Add missing ShareType to known (built-in) types in SimpleSymbolTable
- Define a constructor on generated classes to initialize all the fields
at construction

More coming soon; stay tuned!

Add helper macros for common testing activities including making {keys,
authorities, accounts, producers}, transferring funds, and updating
producers. Replace the boilerplate transaction jockeying in the tests
with these helpers. The tests are now much shorter and more readable. :)

This commit implements and tests the CreateProducer and UpdateProducer
sys contract methods.

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

Also add stream insertion operators for oid<T> and PublicKey, so they
can be used in BOOST_CHECK_EQUAL tests, and also sent over ostreams.

- Move types into eos::types namespace
- Fix lots of bugs in types
- Add tests of types (one still failing)

Break up files, fix a typo here and there... no interesting behavior
changes.

Still getting build errors from fc due to invalid partial template
specializations. Fix by hoisting the compiler flag to fix this from fc up
to eos as a whole.

- 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

Add a test doing some basic sanity checks on account creation

The contract handlers that need the database get a reference to it in
the context. I don't need to pass another db reference to them. Fix
this.

The protocol folder heralds back to BTS, when we drew a distinction
between "protocol objects" and "implementation objects." This
distinction was never really realized, and definitely isn't being
maintained now, so do away with the vestiges. It's nothing but a
potential point of confusion now.

Throw more accurate exception types during trx validation rather than
merely assert_exception's. Also, add a message to the exception
explaining what went wrong.

Previously it was just being done in validate_tapos, which was a legacy
quirk as bts would validate expiration and tapos together. At least now,
there's no overlap between these checks, so they can be split into
separate functions.

Create a new read-write chain API with push_block and push_transaction
calls

The system contract C++ implementation is now in a plugin rather than
directly on database.

Note that testing_database installs this implementation on the testing
database, even though the test framework does not use appbase or appbase
plugins.

This is just an empty template plugin which will serve as a starting
point for new plugins.

Also add a helper script, make_new_plugin.sh, which copies the template
plugin to create your new plugin and automatically renames all of the
files/directories/classes/binaries/whatever. Invoke like so:
./make_new_plugin.sh new_plugin
Afterwards, the new_plugin folder will be ready to go.

The simulated network was recursively calling push_block when
propagating blocks, which caused a lock timeout. Fix this issue by not
pushing a new block to the database that created it.

Also, replace the currently_propagating_block flag with boost's slot
blocker.

Rename: check_tapos -> should_check_tapos
Rename: check_for_duplicate_transactions ->
should_check_for_duplicate_transactions

Since these methods return whether the named action should be taken or
not, rather than taking the named action, prefix their names with should_
so it's clear they're querying and not acting.

Add get_block call to chain read_only api

The beginnings of the chain API is now much closer to the design
described in #14