Model address provenance and expose in peerstore

Nobody has claimed this yet.

The Peer Records epic (#776) introduces a signed record format that contains peer addresses, and makes some changes to the peerstore to support them. However, we've realized that the current design is too restrictive and may break existing systems (e.g. IPFS).

The problem is that, under the current design, the peerstore will stop accepting uncertified addresses for a peer once it has received a signed peer record for them. This seemed sensible, since we want to prefer signed addresses over unsigned in most cases. However, this breaks a few use cases:

- The user types in an address themselves, e.g. `ipfs swarm connect `. We should always try the given address, even if we already have a signed record for the target peer.
- An application-layer protocol with its own signed address scheme should be able to add addresses to the peerstore, even if we've already added our own signed record. We know that Textile is already doing this, and there may be others as well.

So, we need an API that is backwards compatible and continues to accept unsigned addresses even if we have a peer record. However, this means that calls to `peerstore.Addrs(peerId)` will return a mix of both signed and unsigned addrs. We would like to be able to prioritize signed addrs over unsigned addrs when dialing (unless explicitly asked to dial an unsigned addr), so we need to be able to distinguish between them when fetching them from the peerstore.

The proposal is to introduce a "provenance" enumeration to tag an address with its origin, e.g. something like

```go
// AddrOrigin indicates how we (the local peer) learned about a given address.
// Application-layer protocols may define their own custom `AddrOrigin`s if
// e.g. they want to differentiate their custom record format from other origins.
type AddrOrigin string

const (
// OriginUnsignedPeerGossip is the default origin for addresses added through
// AddrBook.AddAddrs and AddrBook.SetAddrs.
//
// An AddrOrigin of OriginUnsignedPeerGossip indicates that we learned about the address
// from another peer by some unauthenticated method. This includes direct exchanges via
// older versions of the Identify protocol, lookups via DHTs that don't support
// peer records, etc.
OriginUnsignedPeerGossip = AddrOrigin("unsigned-peer-gossip)

// OriginNameLookup is the origin for addresses that were obtained by resolving another
// "name-based" address using some kind of lookup protocol, for example, IPNS, DNS, ENS,
// etc.
OriginNameLookup = AddrOrigin("name-lookup")

// OriginLocal is the origin for addresses that are input by a local user, or that we believe
// to be valid from direct observation.
OriginLocal = AddrOrigin("local")

// OriginPeerRecord is the origin for addresses added using CertifiedAddrBook.ConsumePeerRecord.
// An AddrOrigin of OriginPeerRecord indicates that the address was included in
// a peer.PeerRecord signed by the peer to whom the address belongs.
OriginPeerRecord = AddrOrigin("peer-record")
)
```

To support this, we'll need to add methods to the peerstore to add addresses with a specific `AddrOrigin`, and to retrieve addrs annotated with their origin.

Let's discuss what that API should look like in this issue.

@raulk @Stebalien @vyzo @jacobheun @aarshkshah1992 and anybody else that wants to chime in :)

Start by reviewing the peerstore APIs, including AddrBook.AddAddrs, AddrBook.SetAddrs, and CertifiedAddrBook.ConsumePeerRecord. Determine how the proposed AddrOrigin values can preserve unsigned addresses while exposing provenance during retrieval. Done means the API shape and behavior are agreed for adding and fetching annotated addresses.

Written by the indexing model from the issue text.