PubSub & GossipSub configuration proposal

Nobody has claimed this yet.

### Context
#### PubSub spec
The PubSub spec is mostly limited to the wire protocol which is pretty barebones and as a result is open to multiple implementations.

The only "configuration" mentioned in the spec is regarding the `Topic_Descriptor` and the potential for enabling authentication and encryption on the channel. However, the `Topic_Descriptor` protobuf is never actually sent over the wire in the reference `Go` implementation and authentication and encryption are both left not implemented. As a result it is not clear if or how this type of configuration is really intended to be used.

#### go-libp2p-pubsub
While the PubSub spec doesn't have much specified in the way of configurations, the go-libp2p-pubsub implementation does in fact enable a few configurations. These configurations apply to **all** channels of a given PubSub instance and include:
- Blacklisting
- Message signing
- Strict signature validation
- Message routing strategy

Of these configuration options the only one deemed important enough to effect the protocol/contract between nodes is the routing strategy (i.e. "floodsub", "meshsub", etc.). While it makes sense that blacklisting nodes does not need to be communicated at the protocol level other configurations might be relevant (e.g. message signature/verification, persistence, encryption, etc.)

Additionally the common router implementations, such as `FloodSubRouter` and `GossipSubRouter` have a grand total of zero configurable parameters. This means that a slightly modified version of `GossipSubRouter` essentially involves copy-pasting the source into a new router.

### Description of Change

1. I really think that at the very least the `GossipSubRouter` should be extensible enough to allow developers to utilize the underlying protocols for managing the mesh while implementing their own logic for how, when, and which messages get sent along the mesh.

While it may seem like this logic could be layer *on top* of `GossipSubRouter` in fact gossipsub's insistence on (unreliably) fowarding all application messages to peers in its mesh exactly once is too cumbersome for some applications.

2. We should start working on how we'd like to enable protocol extensions to PubSub and GossipSub (and actually implement one)

3. Allow for subscribing to a PubSub topic with one or more configuration options

### Motivation
The motivations for each of the changes above are described in the same order below:

1. There have been requests for a persistent PubSub option for a while. For example, IPNS-over-PubSub is not any faster than IPNS-over-DHT for initial content resolution because PubSub has no notion of persistence. While I could copy-paste `GossipSubRouter` into `LastWriterWinsPersistentGossipSubRouter` and make some changes this feels like a huge maintainability problem. This becomes even more obvious when you take into account that if I wanted to create a scheme for synchronizing multiwriter DAGs over PubSub this would result in yet another copy-paste-modify router.

2. I'm not dead set on enabling protocol extensions immediately because there exists an alternative, which is the developer creating a new protocol ID for each combination of protocol + extensions. However, this does lead to the overhead of dealing with a number of protocol IDs that's exponential in the number of options, so it's something we probably should deal with.

3. I think the DX would likely be better passing config options to `Subscribe()` then creating new `PubSub` instances for every configuration. Also, the system does not behave well if you Subscribe to the same topic with multiple PubSub instances that support the same protocols (e.g. `FloodSubRouter` and `GossipSubRouter` both support the floodsub protocol), so being able to limit the possiblity of this happening would be good. Finally, there's lost efficiency if we have multiple gossipsub-style routers that can't group their messages together because they are managed by different instances.

Because `GossipSubRouter` is backwards compatible with `FloodSubRouter` and message signing/verification are pretty good I doubt people have been needing multiple `PubSub` instances. However, in a world where there are multiple valid configurations and one isn't "better" than another this is bound to happen.

### Proposed Design

Specs: No need to change anything. However, it would be nice to have either of:
1. A bare bones gossipsub spec that focused on the mesh connectivity and left the decisions on when and which messages to forward up to the implementations/higher level protocols. This could make it easier to create new specs that build off the same basic premise just as the abstractions help build reusable code.
2. An extended gossipsub spec that includes a persistence option. The persistence option would have to be triggered at a higher level (e.g. adding a map of router parameters the SubOpts RPC, including them in the protocol ID, etc.). The persistence spec could build off of my existing work at https://github.com/libp2p/go-libp2p-pubsub/blob/3f326121f7228a96827e740dbbd1fc9cc5cc7b62/gossiplww.go

go-libp2p-pubsub: See PR at https://github.com/libp2p/go-libp2p-pubsub/pull/171
1. Modify `PubSubRouter` interface from `Join(topic)` to `Join(topic, protocolID)` and appropriately modify the existing go-libp2p-pubsub `PubSubRouter` implementations.
2. Create a `SubOpt` allowing users to `Subscribe` to a topic with a particular protocol ID
3. Modify `GossipSubRouter` to take in multiple configurations that are associated with particular protocol IDs

### Proposed Next Steps

1. Get feedback and approval for configuration PR to allow for more experimentation (potentially leaving out the LWW implementation)
2. Publish LWW persistent gossipsub spec for community review and improvement
3. Get community feedback on whether anyone else is interested in building off of gossipsub and if there's more configuration to be added going forward
4. Get community feedback on whether we'd like more optionality built into gossipsub or just have lots of protocol IDs

Start by reviewing the configuration PR referenced as #171 and the existing gossiplww.go work. Compare the proposed PubSubRouter, SubOpt, protocol-ID, and GossipSubRouter changes with the four proposed next steps; done means the community has an agreed direction for configuration and extensions.

Written by the indexing model from the issue text.