⚠ this commit makes your current configs unusable, as the
default bootstrap peers. You may need to edit your config.

Go from:

```js
Bootstrap: [
  {
    "Address": "/ip4/104.131.131.82/tcp/4001",
    "PeerID": "QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ"
  }
]
```

To:
```js
Bootstrap: [
  "/ip4/104.131.131.82/tcp/4001/ipfs/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ"
]
```

misc fixes: hanging connects + test output

http://gifs.gifbin.com/012011/1295375531_cat-jump-fail.gif

sharness fixes - gateway and more

Not sure why this fd redirect was here. Is it necessary?
Tests seem to pass for me.

cc @mildred

- core: daemon stdout print to cmd + daemon init checks
- core: fixed bug where the gateway was printed as "API"
- sharness/test-lib: daemon init checks
- sharness/test-lib: portable TCP port check
- sharness/init: fix test bits output
- sharness: use common hashes in one place.
- move t0100-http-gateway -> t0111-gateway-writable
- sharness: test-lib funcs for gateway config
- sharness/t0111-gateway-writable: use sh funcs
- sharness/t0111-gateway-writable: fixes
  - escape all vars (always `cmd "$VAR"` never `cmd $VAR`)
  - use $FILEPATH, not $path
  - last test seems to fail

HTTP: add handlers to allow object creation and modification

online services started before network listens

blockservice/worker: fix proc/limiter sync

addresses CR comments

see: https://gist.github.com/jbenet/6b8b45bde9d9fce17d57

I want to make the goprocess API nicer so it doesnt lead
users into this problem. any ideas?

fix cast panic in ipfs name resolve when daemon is running

Addresses bug #689

cc @whyrusleeping

updated sharness hashes

We had a problem: we were starting all the services with the network
live, and so would miss early messages. We were noticing bitswap
messages not handled (not in muxer). Many of the subsystems expect
the network to _exist_ when they start up, so we split construction
and starting to listen into two separate steps.

this commit moves management of the nat to its own object.
perhaps this can be general enough to work with any host
(not just BasicHost), but for now keeping here.

the nat manager:
- discovers and sets up the nat asynchronously.
- adds any port mappings necessary if/after nat has been found.
- listens to the network Listen() changes, adding/closing mappings

After this commit, client can close individual mappings (without
closing the whole NAT)

About to allow dht to start without local addresses. this is
so that we can initialize the dht and sign it up to listen
on the muxer, before our node starts accepting incoming connections.
otherwise, we lose some (we're observing this happening already).

I looked through the dht's use of the peerstore, and the check here
doesnt seem to be as important as the panic implies. I believe the
panic was used for debugging weird "dont have any address" conditions
we had earlier.

Network now signals when it successfully listens on some address
or when an address shuts down. This will be used to establish and
close nat port mappings. It could also be used to notify peers
of address changes.

address concerns about user interface with new Path type

Cleanup logs