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
> The composer being "owned" by the composed is peculiar.

This is not what's happening here. This is delegating the calling of a teardown function to a _composed_ object. This is a well established pattern in tons of async code, including go libs. This is also the way to handle GC destruction: http://golang.org/pkg/runtime/#SetFinalizer

> The predominant justification for delegating the composer's Close to the context closer seems to be the sync.Once guarantee.

It's not as simple as `sync.Once`!! 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). 

> Sharing memory without synchronization and passing objects without explicit ownership is a client problem and serves as an indication of other issues.

This is unrelated. Really. I suggest you wrestle with _all_ the specific sync issues the context closer solves before attempting to design or change this interface. this is a good start: http://golang.org/src/pkg/net/fd_unix.go in particular look at its destroy and close semantics. http://blog.labix.org/2011/10/09/death-of-goroutines-under-control is a good followup, as `tomb` is very similar. and then convolve all of that with having `context.Context` in the mix.