testbed: refactor TestCase with broken out LoadGenerator interface

[rmfitzpatrick]

Description:
Adding a feature - These changes break out the current testbed.LoadGenerator to an interface of the same name, migrating its (reference) implementation to a new testbed.ProviderSender type. This will allow future test cases (in arbitrary distributions) to use the existing* TestCase flow, but with arbitrary load generator implementations beyond the capabilities of the current one. They also provide a new testbed.NewLoadGeneratorTestCase similar to the existing testbed.NewTestCase that is now called indirectly. I chose this route to not force further signature changes.

In the process of this work, I found a few edge cases that can lead to* races and hanging processes in error scenarios. They've been addressed w/ some minimal synchronization.

Here's a partial* example of a LoadGenerator that can manage an arbitrary number of ProviderSender instances, each of varying telemetry types, that can now be used:

type CompositeLoadGenerator struct {
	startTime      time.Time
	loadGenerators []testbed.LoadGenerator
}

func NewCompositeLoadGenerator(loadGenerators ...testbed.LoadGenerator) testbed.LoadGenerator {
	return &CompositeLoadGenerator{
		loadGenerators: loadGenerators,
	}
}

func (o *CompositeLoadGenerator) Start(options testbed.LoadOptions) {
	o.startTime = time.Now()
	for _, lg := range o.loadGenerators {
		lg.Start(options)
	}
}

func (o *CompositeLoadGenerator) Stop() {
	for _, lg := range o.loadGenerators {
		lg.Stop()
	}
}

func (o *CompositeLoadGenerator) DataItemsSent() uint64 {
	var dataItemsSent uint64
	for _, lg := range o.loadGenerators {
		dataItemsSent += lg.DataItemsSent()
	}
	return dataItemsSent
}

<...>

Documentation:
Updated readme.

[rmfitzpatrick]

I think this is the main breaking change, with Sender now only being available on the ProviderSender instance, which is still available on the LoadGenerator field. In the cases where this was used, the tests already have* access to the sender directly so the indirect access is unnecessary to begin with. I decided to not address potential simplifications* in this initial pass to keep the changes localized to the involved types.