Replace gossipSupport and inline function with an adapter

Within the peer package, createChain sets up a number of config bundle listeners. One of these supports gossip.

The current implementation for gossip involves a gossipSupport struct in the peer that embeds channelconfig.Application, configtx.Validator, and channelconfig.Channel.

type gossipSupport struct {
	channelconfig.Application
	configtx.Validator
	channelconfig.Channel
}

This is rendered as a Config interface:

// Config enumerates the configuration methods required by gossip
type Config interface {
	// ChainID returns the chainID for this channel
	ChainID() string
	// Organizations returns a map of org ID to ApplicationOrgConfig
	Organizations() map[string]channelconfig.ApplicationOrg
	// Sequence should return the sequence number of the current configuration
	Sequence() uint64
	// OrdererAddresses returns the list of valid orderer addresses to connect to to invoke Broadcast/Deliver
	OrdererAddresses() []string
}

In addition to employing the "support" anti-pattern, it violates the tell-don't-ask principle as the object presented to gossip is used to repeatedly get the information from the config bundle.

This needs to be refactored to create a single-responsibility object that acts as an adapter between gossip and the BundleActor. This object should be created with the necessary dependencies and attach a method that satisfies the channelconfig.BundleActor interface. When the BundleActor callback is driven, the adapter should create a value object that contains the necessary data for gossip and calls the gossip handler with the value object.

This approach tells gossip the information it needs, allows the adapter layer to be explicitly tested, and it removes the gossipSupport struct from the peer.