Use newer PeerID as CID representation

As described in the peerID spec there are two ways to encode peerIDs into text.

1. As a base58 encoded multihash
2. Embed the peerID into a CID where the codec is libp2p-key and then encode using multibase

Currently the Encode(peerID) function returns the legacy base58 encoding. It would be nice to start using the CID representation as it will mean that the default representation of Ed25519 keys will be as CIDs. Some implications include:

1. Existing CID tooling could be used to convert PeerIDs into relevant representations (e.g. a lowercase base36 representation for web browsers)
2. Older applications that mistakenly assumed PeerIDs were CIDs will still actually work, even with Ed25519 keys

We'd have to choose what base to encode the CIDs into by default (cc https://github.com/ipfs/specs/issues/247). Two (of many) viable options here are:

• Encode all PeerIDs as CIDv1s using a standard encoding
  • Upside: Consistent representation, can choose nice defaults like base36
  • Downside: Could be problematic for applications that interact with libp2p implementations that don't yet have CID support
• Encode CIDv0 PeerIDs as a standard CIDv0 which is implictly base58, and everything else as CIDv1
  • Upside: Doesn't change anything for applications that are using CIDv0 PeerIDs
  • Downside: Conversion of CIDv0s required if users want to use them in lowercase-only environments. Non-consistent base encoding between standard RSA and Ed25519 keys.

Note: Changing the defaults here may cause problems for applications that interact with libp2p implementations that don't yet have CID support AND are using Ed25519 keys by default.

@lidel has added some context on this here: https://github.com/ipfs/go-ipfs/issues/6916#issuecomment-652099251

^@raulk @Stebalien

Start with the Encode(peerID) entry point and the peerID encoding section of the linked libp2p specification. Review the linked IPFS issue for compatibility context, then determine which CID version and default base should be selected. Done means the default representation and its compatibility implications are resolved and implemented consistently.