Refactor how Add() / Remove() are customised

[jchesterpivotal]

In Skenario the Stock is a key object; different parts of the simulation are expected to mostly locate their logic in Add() and Remove().

In the current implementation this is achieve with a subclassing-like structure. For example, ReplicasDesired:

type ReplicasDesiredStock interface {
	simulator.ThroughStock
}

which then uses an internal delegate stock to handle some tasks:

func (rds *replicasDesiredStock) Name() simulator.StockName {
	return rds.delegate.Name()
}

func (rds *replicasDesiredStock) KindStocked() simulator.EntityKind {
	return rds.delegate.KindStocked()
}

func (rds *replicasDesiredStock) Count() uint64 {
	return rds.delegate.Count()
}

func (rds *replicasDesiredStock) EntitiesInStock() []*simulator.Entity {
	return rds.delegate.EntitiesInStock()
}

But where Add() and Remove() are fairly extensive, as they describe the actual logic of interest.

This sub-ish class-ish approach works well enough and it's a relatively consistent pattern across the codebase. However it's a bit tedious to write tests over and over to ensure the delegate is properly wired.

It might be easier to change this relationship into a factory function of some kind. Pass in the Add() and Remove() function bodies and get back a wired-up Stock. This would reduce some of the boilerplate and repetitive testing.