Improve IPNS spec

The IPNS spec currently combines a lot into a single document and leaves some issues ambiguous. The main issues to tackle are:

1. Terminology
- Spec names of IPNS path components:
- `/ipns/`
- `/ipns/bafy...`
- `/ipns/bafy.../images/pic.jpg`
- `bafy...`
- `/images/pic.jpg`
2. Data Types (mostly in the spec already)
3. Networking and Protocol spec
- Existing router behaviors
- dht
- pubsub
- dns
- IPNS protocol
- What must be implemented to be considered IPNS?
- How is behavior in the presence of multiple routers defined?
- publish strategy
- republish/pinning strategy
- resolve strategy
- define specifications new routers must meet (e.g. must it support third party republishing, must it
- If streaming updates from resolve (or to publish) is part of the spec it should be defined
4. Other
- Do we want to spec out any implementation suggestions or defaults?
- Do we want to specify any extensibility points up front, or just PR the spec in the future?
- Be explicit about DNSLink in `/ipns/` namespace:
- why we allow DNS names? what are the rules of interop? is there a plan to change current situation?
- is supporting DNSLink required by IPNS implementers?
- how should IPNS implementers who don't support DNSLink denote the IPNS namespace?

refs:
https://github.com/ipfs/specs/issues/198

/cc @aschmahmann @lidel