- 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

Add README with build and run instructions

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.

The macros to make testcases less tedious to write had opaque
abbreviated names like UPPDCR (my own fault, I know haha). Replace those
names with obvious ones like Update_Producer.

Also, sweep all the backend/implementation detail macros into
macro_support.hpp where they are hidden out of the way and unlikely to
be accidentally used directly.

Unify types

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.

- 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