Skip tons of duplicate GetHash() calls in Block Commit Thread #1486

The goal is for p2p code/wallet to only get information/communicate
information about the blockchain through CHub, giving Bitcoin a
much more clearly-defined structure and allowing for the removal
of a ton of the current global mess.

Replacing ProcessBlock with EmitBlock, and creating callbacks for
CommitBlock.

Also rename NotifyBlocksChanged to NotifyNewBlock and remove from
the uiInterface signals list.

This removes some functionality, but NofiyBlocksChanged was not
used anyway, so it shouldn't matter.  That said, if it is ever
needed, it would be fairly trivial to add a new callback for it
in CHub.

Replace ProcessAlert with calls to EmitAlert and create callbacks
for CommitAlert.

There was no reason to use CDataStream as the transaction was
already being serialized/deserialized several times, with this
change, transactions coming in over network are deserialized once
when received, and then only reserialized in the call to
RelayMessage, which will be called in a callback thread, not
blocking cs_main.

 * This removes not only CTransaction::AcceptToMemoryPool, but
    also CMerkleTx::AcceptToMemoryPool. It also moves
    CWalletTx::AcceptWalletTransaction to wallet.cpp

 * This adds a fCheckInputs flag to EmitTransaction, which is
    similar to the fCheckInputs flag to AcceptToMemoryPool,
    however, it has stricter guidlines that it should only be set
    "when transaction is a supporting tx for one of our own."
    Additionally, "fCheckInputs is ignored (and set to true)
    if !IsInitialBlockDownload() && !fClient"

    As a part of these guidelines,
    CWalletTx::AcceptWalletTransaction calls EmitTransaction with
    fCheckInputs set to true (the default) on the final
    transaction, whereas it used to call with fCheckInputs set to
    false. This has the important side-effect of allowing wallet-
    generated transactions to end up getting AddOrphanTx'd.
    However, if a supporting transaction to one of our own had
    previously been AddOrphanTx'd, it would immediately be added
    to memory pool as it is "a supporting tx for one of our own"
    and thus is re-added with fCheckInputs=false.

    Note that the possibility of a wallet transaction getting
    AddOrphanTx'd is very low, and should only happen if
    a) a transaction's input is a generate and we are missing that
       block (note that no transactions should be generated with a
       generation input if we don't have that block anyway).
    b) We match the !IsInitialBlockDownload() && !fClient check,
       are not caught up to the latest block, and an input is in a
       block we do not yet have (possible after the last
       checkpoint). This situation is temporary and should resolve
       itself once we catch up (though AddOrphanTx'd transactions
       may be permanently orphaned).

    Largely, these guidelines are there because there is no reason
    to add a transaction without checking its inputs, as we have
    those inputs available, and checking them as any other
    transaction would provides additional sanity-checks.

 * A second EmitTransaction was added with tx of type CMerkleTx.
    This keeps behavior of CMerkleTx::AcceptToMemoryPool the same
    in fClient mode. Note that new behavior was invented for
    CHub::EmitTransaction(CTransaction&...) in fClient mode,
    namely that ClientConnectInputs is only checked if
    fCheckInputs is true. This was chosen to make emitting a
    transaction possible in fClient mode even if its inputs are
    not available, but could be changed if support for that is not
    needed when fClient mode is actually implemented.

Note that this changes the way the GUI shows coinbases of users:
it now shows them only after the first non-orphan block based on
the generating block, instead of after the first block based on
the generating one period.

This removes the locking of cs_main before calling Emit* and should
allow multiple ProcessMessage calls at once.

It no doubt locks cs_main in places where it isnt neccessary, but
to avoid complicated and unforseen interactions, cs_main is locked
for nearly every message in ProcessMessage.

It has a fBlocking flag to wait for the block being requested to
be committed after having been emitted (for use in the
"force request" block request in the "inv" message handler).

This fixes a potential segfault if -blockbuffersize is overly big.

This resolves a bug where the block buffer is allowed to deplete
because the getdata that is required to continue is not sent.

This keeps the block buffer from running out until the final
block's FinishEmitBlock is run.