Treat non-final transactions as non-standard

At least one service that accepted zero-confirmation transactions
was vulnerable because an attacker could send a transaction
with a lock time far in the future, and then have plenty of time in
which to get a double-spend mined (perhaps from a miner who wasn't
on the network when the first transaction was broadcast).

That is a variation on the "Finney attack". We still don't
recommend anybody accept 0-confirmation transactions as final
payment for anything. This change keeps non-final transactions
from appearing in the wallet, and, assuming most of the network
accepts this change, will prevent them from being relayed until
they are final.
Use a copy in place of mapMultiArgs["-addnode"].

Also moves the DNS lookup of -addnode nodes into the repeated
loop, allowing -addnode to follow DNS changes.
Make ThreadOpenAddedConnections2 exit quicker if(GetNameProxy()).
Add addnode RPC command.
Add a getaddednodeinfo RPC.
Try more than the first address for a DNS -addnode.
Merge pull request #2223 from gavinandresen/nonfinalnonstandard

Treat non-final transactions as non-standard
Merge pull request #1549 from TheBlueMatt/addnoderpc

Addnode optimization and addnode access via RPC