next 2012-08-13 #1671

- Show address receiving the generation, and include it in the correct "account"
- Multiple entries in listtransactions output if the coinbase has multiple outputs to us
- Classify generation as "receive" category, so it doesn't require special treatment for payment services
- Add new "status" key to wallet transactions, which is:
- - "confirmed"  -- 6+ confirmations (120+ for generation)
- - "processing" -- 2+ confirmations (100+ for generation)
- - "validating" -- 0+ confirmations (  1+ for generation)
- - "invalid"    -- negative confirmations (contradicted in main chain)

"Version 2" blocks are blocks that have nVersion=2 and
have the block height as the first item in their coinbase.
Block-height-in-the-coinbase is strictly enforced when
version=2 blocks are a supermajority in the block chain
(750 of the last 1,000 blocks on main net, 51 of 100 for
testnet). This does not affect old clients/miners at all,
which will continue producing nVersion=1 blocks, and
which will continue to be valid.

If 950 of the last 1,000 blocks are nVersion=2, reject nVersion=1
(or zero, but no bitcoin release has created block.nVersion=0) blocks
-- 75 of last 100 on testnet3.

This rule is being put in place now so that we don't have to go
through another "express support" process to get what we really
want, which is for every single new block to include the block height
in the coinbase.

For backward compatibility, new accounting data is stored after a \0 in the comment string.
This way, old versions and third-party software should load and store them, but all actual use (listtransactions, for example) ignores it.

Logic:
- If sending a transaction, assign its timestamp to the current time.
- If receiving a transaction outside a block, assign its timestamp to the current time.
- If receiving a block with a future timestamp, assign all its (not already known) transactions' timestamps to the current time.
- If receiving a block with a past timestamp, before the most recent known transaction (that we care about), assign all its (not already known) transactions' timestamps to the same timestamp as that most-recent-known transaction.
- If receiving a block with a past timestamp, but after the most recent known transaction, assign all its (not already known) transactions' timestamps to the block time.

- Replaces getmemorypool with new getblocktemplate
- Add missing keys: coinbaseaux, target, mutable, noncerange, sigoplimit, sizelimit, and height
- Accept and send parameter Objects, checking "mode" key if present
- Return rejection reason "rejected" for submit mode

Conflicts:
	src/bitcoinrpc.cpp

Also moves the DNS lookup of -addnode nodes into the repeated
loop, allowing -addnode to follow DNS changes.

Accepts the transaction into mined blocks at a higher (or lower) priority

Conflicts:
	src/main.cpp