Daemon code

This pull request allows ipfs to run as a daemon that is communicated to via a TCP socket. When the daemon is running, all 'ipfs' commands will be run on the daemon process as opposed to the ipfs command process.
_The Go Way_ of handling errors is to try to be honest with callers about errors that arise during operation. The construction of large systems is simplified through the combination of (1) Systematic propagation of errors and (2) well-defined caller/callee contracts.

There's always some place where the buck stops, but I'm often cautious of silencing errors too early. Doing so deep in the call stack limits one's ability to handle exceptional control flow. 

When a choice is made to handle an error rather than bubbling it up, it's important to have a principled reason for the course of action.

In this case, it looks like the error isn't returned because the system wishes to express specific messages about the nature of the failure. The language-provided mechanism for this is to instantiate an error with a detailed message. This error can be returned to the caller and the caller can choose what to do with it.

``` go
if err != nil {
  return errors.New("This is a really bad error")
}
return nil
```

https://golang.org/doc/effective_go.html#errors

Admittedly, there are alternate approaches (eg. exceptions in Python), but since the standard library takes such a hard stance in favor of error objects and multiple return values, it is often best to go with that flow rather than defy convention.


One caveat: In asynchronous contexts, it can sometimes be difficult to get return errors bubbled up to interested parties. In those cases, it often comes down to a well-considered judgement call.