Memory management improvements

[cbarrick]

One space optimization for evolutionary algorithms is to reuse the space of dead genomes to reduce (even eliminate) allocations during the main loop. In the current API, Evo encourages using a finalizer to recycle the memory. To make this as easy as possible, Evo allows the user to define a Close method that gets registered as a finalizer. In the examples, the Close methods use a sync.Pool to handle the memory recycling.

There are a couple problems here. First, finalizers are not guaranteed to run. This means the Close method has no real meaning in the API because Evo may ignore it. If the genome MUST cleanup resources, the user is forced to do this without relying on the Close method. Second, a sync.Pool frees the recycled but unused memory at each GC cycle. This limits the extent to which the optimization is valuable.

Addressing the first problem, we could remove the Close method from the Population interface. This should have minimal backwards-compatibility implications since the method is not guaranteed to be called in the first place. A difficulty arises when we use a pool selector for replacement in that the user does not know when a genome is being discarded. We could incorporate the cleanup into a pool selector, and this may involve some kind of generic selector.

As for the second problem, we can simply introduce our own long-lived free list type. This should be trivial relative to the sync.Pool type since we don't need to interact with the runtime.

[cbarrick]

I'll likely end up removing the Close hook all together. I've been unable to observe any real performance benefit from using it. See #13 to follow the progress on this.

[cbarrick]

The Close hook has been removed all together. The Go runtime seems to be pretty good at managing memory without our intervention.