Now we calculate the round changes and store them in generate_block.

Progress:
- When an account adds/removes stake, we now update votes for its
approved producers
- Name map<AccountName, AccountName> as RoundChanges, and define
operator- such that RoundChanges = ProducerRound - ProducerRound

Test the vote updates, making sure that producer votes are updated when
an account adds stake

TODO: Calculate the producer round changes in generate_block and add to
block header

Calculating the new producer schedule based on votes is now implemented;
however, the voting itself is not. :D But the code builds, and the tests
pass. It's good progress, it's been a good day.

Note that "the tests pass" means little at this stage, since I haven't
written any new tests to exercise the new code. In other words, NEEDS
TESTING!

- Rename config::ProducerCount -> config::BlocksPerRound
- Add new config::VotedProducersPerRound = 20
- Split up staked_balance_objects.hpp moving ProducerVotesObject to
producer_objects.hpp

Add producer schedule changes to block_header, so light clients can see
the round changes by just watching block headers.

Implement changing the producer schedule at round changes, first checking
that the schedule changes in the block_header are correct, then applying
them.

TODO: Actually calculating the new round (right not it never changes)

Wire protocol specs say never to put an id_type on the wire, but
block_header contained the id_type for the producer which created it.
Fix this by using the AccountName of the producer's owner instead.

The producer-median-voted blockchain configuration parameters are now
updated when the round changes. The previously expected-failing test
case for this now passes

This new interface allows the chain_controller to request a fresh round
of producers and request the producers' median voted blockchain
configuration.

Net yet complete, but integrated sufficiently to get the tests to pass.

And rename it to chain_initializer_interface

Previously, we created the initial producers by manually making the
producer_object's in prepare_database. Now we create them by creating
Messages directing their creation, and invoking the normal
CreateProducer infrastructure.

Ohh, my life would've been easier during my last commit if that rename
had actually been done rather than just commented about.

OK, so this turned out to be a **massive** refactor that I thought I'd
never finish, and no, I don't remember everything that changed here, but
I think it all worked out to be better than before, and almost all of it
was fairly necessary/the best of available options. Whew. I am SO glad
this is finally done.

High level goal: Continue refining the native contracts (ref #15),
specifically
walling off their state into their own contract DBs rather than globally
shared (read: stuff that race conditions are made of) general blockchain
state.

The first real change I made in this commit, which precipitated the
avalanche of changes that followed before the project became consistent
again, was to move the account balance out of account_object (globally
shared) to an object known only to the Eos Contract, thus eliminating
the possibility of race conditions/nondeterministic behavior.

The trouble is, balances are set at genesis. Genesis is processed by
chain_controller. chain_controller cannot know about balances, since
those are an abstraction defined on top of the Eos contract, which is an
abstraction defined on top of chain_controller. So all of genesis had to
be reimagined, and quite a lot of architectural changes had to be made
in order to create a logically consistent solution.

Changes (probably incomplete):
 - Fix up notifications within the native contract to support
precondition validation as well as application

 - Add notify handlers for CreateAccount to Eos and Staked Balance
contracts

 - Move account's liquid balance of EOS from account_object to
BalanceObject

 - Replace {producer,account}_object::id_type with AccountName most
everywhere except block_header, which still contains a
producer_object::id_type (potentially in violation of protocol
standards, but I want to confirm that before fixing it)
   - Reason: The name is not significantly slower, as it's fixed length so
no heap allocs, and it simplifies the code in quite a few places by
allowing us to look up objects directly rather than indirectly by
looking up an ID to get an intermediate object to get a handle for the
object we really wanted

 - Replace native_system_contract_plugin with native_contract library
   - Reason: The plugin was getting in the way. The native system
contract C++ implementation is simply too fundamental unless/until we
have a scripted implementation that works until the native
implementation gets installed

 - Completely reimagine genesis initialization, taking it largely out of
the hands of chain_controller and putting it in the hands of
native_contract
   - Reason: chain_controller understands relatively little about
genesis. It understands global_property_object and producer_object, but
not BalanceObject or StakedBalanceObject, etc... It also doesn't
understand the native_contract, and things like installing the native
contract, setting up accounts/balances, etc. all need to be handled by
something... native_contract is the most logical place to put it.

Sorry for the enormous commit... alas, this was the first time I got it
all building again and passing tests in days.

Create all three native contracts at genesis, and split the various
messages among them appropriately.

- remove BTS P2P code which depended on fc threads which depended on
deprecated boost::context API

- remove fc submodule and making fc part of eos repository

This completes the refactor (to a buildable/tests passing state) from my
last commit.

- Break apart chain_controller, so it doesn't inherit
chainbase::database
- Reorganize chain_controller, database (and whatever else) towards
dependency injection
- Reorganize chain_controller, database (and whatever else) towards RAII

Rename database class to chain_controller, as this class manages
blockchain state and operations. Database was a misnomer.

Next step: make chain_controller a free-standing class, rather than
having it inherit from chainbase::database. This should give us a better
architecture, especially for testing, going forward.

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 implements and tests the CreateProducer and UpdateProducer
sys contract methods.

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.

- 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

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.