Organising option flags

Nobody has claimed this yet.

As users demand more functionalities (e.g. #34), we're likely to see a proliferation of option flags for the daemon binary. While the daemon is marked as an _experimental_ project, we should attempt to bring in structure to our option flags. Let's agree on an approach and lock it in.

Proposal:

* Let's be idiomatic. I found that camelCasing flags is not really idiomatic in Go: `go test` uses no casing or separators, and `ipfs` uses hyphens. My proposal is to use hyphens.
* Let's namespace our flags.
* Let's strive for consistency. Consistency can look different in each namespace, e.g. for transports, we can make all flags additive (a flag adds support for a transport), and provide a single subtractive flag to disable OOTB defaults. The connection manager deals with values, so it'll look different.

For transports, this can look as follows:

```
-tpt-enable-quic enables the QUIC transport
-tpt-enable-ws enables the WebSockets transport
-tpt-enable-tcp enables the TCP transport
-tpt-disable-defaults disables the default transports
```

So if I wanted to enable ONLY QUIC, I'd do the following:

```
p2pd -tpt-disable-defaults -tpt-enable-quic
```

WDYT? CC @vyzo @bigs @jrhea @cheatfate @mhchia

Start by reviewing the daemon's existing option flags and issue #34, then compare the proposed hyphenated, namespaced transport scheme with current behavior. Done means the project reaches a decision on flag naming, namespacing, and per-namespace consistency.

Written by the indexing model from the issue text.