Reject non-canonically-encoded sizes

The length of vectors, maps, sets, etc are serialized using
Write/ReadCompactSize -- which, unfortunately, do not use a
unique encoding.

So deserializing and then re-serializing a transaction (for example)
can give you different bits than you started with. That doesn't
cause any problems that we are aware of, but it is exactly the type
of subtle mismatch that can lead to exploits.

With this pull, reading a non-canonical CompactSize throws an
exception, which means nodes will ignore 'tx' or 'block' or
other messages that are not properly encoded.

Please check my logic... but this change is safe with respect to
causing a network split. Old clients that receive
non-canonically-encoded transactions or blocks deserialize
them into CTransaction/CBlock structures in memory, and then
re-serialize them before relaying them to peers.

And please check my logic with respect to causing a blockchain
split: there are no CompactSize fields in the block header, so
the block hash is always canonical. The merkle root in the block
header is computed on a vector<CTransaction>, so
any non-canonical encoding of the transactions in 'tx' or 'block'
messages is erased as they are read into memory by old clients,
and does not affect the block hash. And, as noted above, old
clients re-serialize (with canonical encoding) 'tx' and 'block'
messages before relaying to peers.
[Fee logic] Don't count txins for priority to encourage sweeping.

This changes the priority calculation to not include the size of per-txin
 data including up to 110 bytes of scriptsig so that transactions which
 sweep up extra UTXO don't lose priority relative to ones that don't.

I'd toyed with some other variations, but it seems like any formulation
 which results in an incentive stronger than making them not count will
 sometimes create incentives to add extra outputs so that you have
 extra inputs to consume later.  The maximum credit is limited so that
 users don't lose the disincentive to stuff random data in their
 transactions, the limit of 110 is based on the size of a P2SH
 redemption with a compressed public key.

This shouldn't need a staged deployment because the priority is not
 used as a relay criteria, only a mining criteria.
Remove CENT-output free transaction rule when relaying

Remove the (relay/mempool) rule that all outputs of free transactions
must be greater than 0.01 XBT. Dust spam is now taken care of by making
dusty outputs non-standard.
Lower maximum size for free transaction creation

Changes the maximum size of a free transaction that will be created
from 10,000 bytes to 1,000 bytes.

The idea behind this change is to make the free transaction area
available to a greater number of people; with the default 27K-per-block,
just three very-large very-high-priority transactions could fill the space.
make appbundle target for OSX development

Adds an 'appbundle' target that creates a top-level Bitcoin-Qt.app/
Modifies the 'deploy' target so that it leaves behind Bitcoin-Qt.app;
make clean will remove it.
Added better WalletTools description.
Merge pull request #3103 from gavinandresen/appbundle

make appbundle target for OSX development
Merge pull request #3008 from gavinandresen/CENTrule

Two small free transaction policy changes
Merge pull request #2884 from gavinandresen/canonicalsizes2

Reject non-canonically-encoded CompactSize
Merge pull request #2945 from gmaxwell/fee-logic_encourage_sweeping

[Fee logic] Don't count txins for priority to encourage sweeping.
Merge pull request #3106 from super3/master

Added better WalletTools description.
Merge pull request #3109 from laanwj/2013_10_remove_walletstack

qt: merge walletstack and walletframe
qt: rework "receive coins" workflow
qt: remove verify/send message and send coins from address book

These no longer make sense in the new workflow. It's less
clicks to reach sign/verify message from the menu. And sending
from the address book is one kind of automatic address reuse
we're trying to avoid.
qt: allow dragging, copying and saving QR code

Add context menu and drag handling to QR code widget.
qt: add message field to SendCoinsRecipient

Also update URI parsing to fill in this field.
Note that the message is not currently used in any way with the client.
It should be stored with the transaction.
qt: use SendCoinsRecipient for payment request information

This brings some symmetry into the design by using the same object
both for incoming URIs that are parsed as for outgoing URIs that
are formatted.
qt: move bitcoin URI formatting to guiutil

Follow the same pattern as the parseBitcoinURI function.
qt: show payment information in one text area

Simplifies the dialog (makes it look less crowded) as well
as the code and makes it possible to copy multiple fields at once.
Also format bitcoin URI as URI, add copy button for URI.
qt: general polish after adding new receive flow

- We no longer have an address book, but "address lists", update message
  accordingly
- Add tooltips here and there
- Clarify text on buttons
- add Copy Address button to receive request dialog