Normalize custom function interfaces

[chrisbloom7]

The 4 custom functions - energy_calculator, state_change, cool_down, and termination_condition - all have different method signatures that need to be adhered to when overriding them. I think we can normalize them pretty easily to make documenting their use a little easier.

• Both energy_calculator and state_change currently expect one argument: the state of the current Metal instance being evaluated.
• The newest function, cool_down, expects 4 arguments: the energy and temperature of the current Metal instance, the current cooling_rate config that has precedence (i.e. local versus global), and finally the steps the annealer has taken which make it possible to do exponential temperature reductions, etc. *
• The termination_condition expects 3 arguments: the state, energy, and temperature of the current Metal instance *

With the exception of the cool_down function, all of the arguments are things the current Metal instance can tell us. So, I propose we:

• Create a static, idempotent object that represents the current state of the annealing process during any given iteration. (Suggestions: Annealing::Step) Specifically, it would know the current state, energy, and temperature of the current metal instance, as well as the current cooling_rate and iteration (aka step) of the annealing simulator. The benefit of using a different class than Annealing::Metal is that some metal methods are not idempotent and shouldn't be called from outside the simulator itself, plus it lets us add info about the current simulation step without requiring Metal to start tracking things external to its own purpose.
• Update the 4 custom function signatures to each accept a single argument representing this new object. Everything there is to know about the current state of the simulation becomes available to those custom functions and we don't have to try to guess at what might be helpful to someone in the future. And if we do need to add something, we can add it to to this new class and then it's available to all of the custom functions to use.

* For the two newest functions I could only make a reasonable guess as to what data might be helpful for all future use cases, though for my own purposes I only cared about cooling_rate and steps for the cool down function, and only energy for the termination condition.

[chrisbloom7]

Was doing some more reading about SA implementations in preparation for a presentation and noticed that some SA solutions choose a neighboring state as a function of k (where k might be the current iteration or current temperature, depending on if the algorithm supports reannealing) and where the new state is selected based on a probability distribution of scale k. Mentioning this as another argument in favor of having greater visibility into the current state of the annealer from state_change