Revisit peer-id string representation

[wemeetagain]

See https://github.com/libp2p/specs/blob/master/peer-ids/peer-ids.md#string-representation

Specifically:

Libp2p is slowly transitioning from the first (legacy) format to the second (new).

and

Implementations SHOULD display peer IDs using the first (raw base58btc encoded multihash) format until the second format is widely supported.

Perhaps its time this language is changed to be more definitively in favor of the 'new' encoding.
Opening issue for discussion.

[mxinden]

Referencing tracking issue here: #216

[burdiyan]

Would be great to have some guidance on this one. We (Mintter) currently store and work with PeerIDs in the CID form, but it often causes issues with debugging, because logs and everything else in the ecosystem is still using the multihash form of PeerIDs.

Using the CID form in the IPLD data also sometimes causes problems when looking at the IPLD data using the IPLD Explorer UI — it treats those as IPLD links (which is fair), but complains about not being able to resolve or decode data using the libp2p-key CID codec.

[mxinden]

@burdiyan I don't think Thomas or I will prioritize this any time soon. That said, happy to guide you contributing this change.

[burdiyan]

My point was mostly to get some recommendations about which PeerID forms to use storing in IPLD, keeping in memory, outputting in the UI and CLI?