feature: machine-readable logging

updated:

This PR adds support for machine-readable logging. Here's the skinny:

The `eventlog` package extends our existing logging functionality to provide structured, machine-readable logs. It exposes the `eventlog.Logger` which wraps the `util.Logger`, making it a drop-in replacement.

``` go
var log = eventlog.Logger("dht")

func processMsg() error {
    log.Debugf("msg received from %s", p.ID.Pretty()) // delegated to existing util.Logger

    log.Event(ctx, "messageReceived", p, pbmsg) // goes to the machine-readable logger
}
```

By implementing the `Loggable` interface, objects marshal themselves into `map[string]interface{}` with keys that are consistent across the entire project.

``` go
type Loggable interface {
  Loggable() map[string]interface{}
}
```

By default, logs are written to `~/.go-ipfs/logs/events.log` as line-delimited JSON. This can be overridden at config initialization _or_ updated from the CLI with `ipfs config`. The init override flag has not yet been exposed.

```
{"event":"sentMessage","localPeer":{"id":"EiCsOiFNw0RDqkoNuVeGtGoz4JrHVdLoZhOBhU7dbaSOCg==","latency":0},"message":{"type":"PING"},"system":"dht","time":"2014-11-16T14:04:45.554426994Z","remotePeer":{"id":"EiCwSlfUDsoTiAnxOadrEgRDM8N0A5HJvxzp2OIaeSEL/Q==","latency":0}}
```

Log initialization is performed as a pre-command hook. We take care to not read the config when the executing command will not read the config.

Now we can grep our logs and transform them for protocol-agnostic analysis.

``` go
func main() {
	f, _ := os.Open("events.log")
	r := bufio.NewReader(f)
	for {
		ldjson, _, err := r.ReadLine()
		if err != nil {
			return
		}
		json, _ := simplejson.NewJson(ldjson)
		e, _ := json.Get("event").String()
		fmt.Println(e)
	}
}
```

```
interfaceListenAddresses
interfaceListenAddresses
sentMessage
interfaceListenAddresses
interfaceListenAddresses
sentMessage
```

**future work**
* implement leveled logging (we need to decide what levels we want for the structured logs)
* expose a flag to override log directory
* remove the logrus dependency

**dependencies**
`logrus` (MIT) aims to provide functionality similar to our `eventlog` package. While leveraging `logrus` allows us to keep our package small while we iterate on the design, I recommend we move off of this once we make decisions about 1) leveled logging and 2) alternatives to statically importing `var log = Logger(package)` in client packages.

`lumberjack` (MIT) provides log file rotation. I predict it will be quite useful as a medium/long-term dependency.

**additional info**
* this package is _very loosely_ connected to util.Logger. If desired, we can easily separate it entirely. I left them together to ease the transition.
> I'm suggesting that the client use a method on the Peerstore to explicitly add/create a peer. 

Ah, I thought the code meant to instantiate + use a Put. But I disagree with this too. Everywhere we need a peer we'll need to add explicit check + add statements, which is painful because peers can be generated in many places. I prefer to think of peer objects as _always existing_. I.e. _you always have a Peer object_, it may just only hold the id you used to get it. If the information you want to get is the knowledge that a peer was _just constructed_, I'd prefer the following change:

```Go
type Peerstore interface {
  
    // Get returns the peer for given ID, whether it was just introduced, or an 
    // error, if the something went wrong retrieving the Peer.
    Get(id ID) (peer Peer, created bool, err error)
}
```

> I've described before, a desire to remove all mutating methods off of peers and perform all mutations on the peerstore itself... leaving clients with only read-only handles to peers.

Yeah, file descriptor style. Yeah, this might be TTRTD. Not sure yet. Problem is though that updating a peer would then require locking the peerstore too, not just the peer. (btw, i'm not sure the latency measurements belong in peer/peerstore anyway. It may make sense to have a

```Go
type PeerNetMetrics struct {
  bytesSent int64
  bytesRecv int64
  latency   time.Duration
  ...
}

type NetMetrics struct {
  sync.RWLock

  m map[peer.ID]PeerNetMetrics
}
```

BTW, this suggests another change-- maybe peer.ID should be a `string` after all. Would cut down use of the damn `u.Key` all over the place. We can always convert to []byte when necessary. thoughts? cc @whyrusleeping