Don't use indexing of AtomTypes for data access

[trisyoungs]

Many aspects of the code, in particular the PartialSets generated by the correlation function modules, rely on accessing square 2D arrays of data where the row/column indices are intended to correspond to the AtomTypes as ordered in an associated AtomTypeList.

This is satisfactory for single-configuration simulations which are, at present, the predominant use case, however such an access mechanism is inherently unreliable going forward, as the ordering (and hence indices) of objects in an AtomTypeList as constructed across different places in the code cannot be guaranteed to be consistent, or indeed complete.

The dependence on AtomType indices should be removed, and a more "dynamic" approach to accessing data in those objects should be considered. Typically, such operations are not used in time-critical portions of code, and so a suitable lookup-style approach should be sufficient.

Related to #289.

[trisyoungs]

There are, as suggested above, places in the code where performance is not an issue - e.g. when manipulating PartialSets. There, a std::map of std::maps based around AtomTypes might be all that is required.

However, the key consideration to make is that calculating any energy and force between Atoms requires the indices of the AtomType so that they can be looked up as fast as possible in an Array2D of Potentials. As highlighted in #289 this index information must be local to the Atom class in order to remain performant, so we arrive at the only likely possibility for improvement being to ensure that our centralised PotentialMap is consistent with the indices of the available AtomTypes.

[trisyoungs]

Closed via work in develop2