feat(daemon) `ipfs daemon --initialized`

With this PR, users can fetch and run ipfs in _one_ command.

```
docker run -d -p 4001:4001 -p 5001:5001 jbenet/go-ipfs daemon --initialized
```

Magic.

nb: needs https://github.com/jbenet/go-datastore/pull/9
My concern isn't with the abstract notion of the closer. I understand its purpose.

> ContextCloser enforces very strong guarantees regarding when the object is fully closed, and guiding all interested parties (including children who receive a close signal, and must tear down, clients who may be listening on <-Closed(), <-Closing(), and clients who call .Close() and all block until .Close is done).

If the composer were to call closer.Close(), wouldn't that leave dependents with the same guarantee?

We've talked about this at length on more than one occasion. We've discussed specific issues and things that need to be addressed. As stated before, these are my primary concerns:

* attaching contexts to objects is an anti-pattern. The context closer encourages the practice. My fear here is that the closer is encouraging something we should try _very_ hard to avoid.

* bundling the tomb and the context. It's very possible to mix two simple entities into something that is no longer simple. The entities are simple and well-understood when viewed individually. When the closer is bundled with a state-held context, the interactions are troublesome. Contexts don't work well when carried as state on an object. Contexts work effectively when threaded down call stacks as arguments to functions.

* manual reference counting of spawned goroutines is not a safe, scalable practice. It's easy to make mistakes.

For these reasons, until these issues have been addressed, I believe it is important to contain the construct and manage its use carefully.

The areas of the codebase that are most tricky (and I presume cause your heart to skip a beat when you see edits happening in them) are the ones where the context closer is used to manage tricky interactions and lifecycle management. Not so?

In these early stages of development, malleability is an important property of the system to protect.