Add new "bitcoin-tx" command line utility

This is a simple utility that provides command line manipulation of a hex-encoded TX.  The utility takes a hex string on the command line as input, performs zero or more mutations, and outputs a hex string to standard output.

This utility is also an intentional exercise of the "bitcoin library" concept.  It is designed to require minimal libraries, and works entirely without need for any RPC or P2P communication.

The command line help provides a list of the mutations available:
```
Usage:
  rawtx [options] <hex-tx> [commands]  Update hex-encoded bitcoin transaction
  rawtx [options] -create [commands]   Create hex-encoded bitcoin transaction

Options:
  -?                      This help message
  -create                 Create new, empty TX.
  -json                   Select JSON output
  -regtest                Enter regression test mode,instantly.
  -testnet                Use the test network

Commands:
  delin=N                Delete input N from TX
  delout=N               Delete output N from TX
  in=TXID:VOUT           Add input to TX
  locktime=N             Set TX lock time to N
  nversion=N             Set TX version to N
  outaddr=VALUE:ADDRESS  Add address-based output to TX
  outscript=VALUE:SCRIPT Add raw script output to TX
  sign=SIGHASH-FLAGS     Add zero or more signatures to transaction
      This command requires JSON registers:
      prevtxs=JSON object
      privatekeys=JSON object
      See signrawtransaction docs for format of sighash flags, JSON objects.

Register Commands:
  load.NAME=FILE         Load JSON file FILE into register NAME
  NAME=JSON-STRING       Set register NAME to given JSON-STRING


```

@laanwj Sure, it was just a quick suggestion to help with readability.

For the sake of discussion: this iterator is random access, so it'd be a constant complexity. Imo it's good practice to use iterators when looping through a container and touching each (non-primitive) element. The life-cycle and validity semantics are more clear to the reader, and the const_iterator would make its purpose explicit. I'll agree that std::distance is a bit obscure, so a separate incrementor would've probably been a better suggestion here.