Fingerprints_range in v0.4

[andrew_peterson]

In v0.4, the fingerprints_range is saved in two places (a bad practice): sfp and param, and they aren't necessarily kept synced. This creates a bug in certain situations: one is described:

1. The user trains a neural network to 10 images. The fingerprints_range is saved with the saved parameters in a json file.
2. The user uses the trained NN as a starting point to train a neural network to 15 images. A this stage the train method re-calculates the fingerprints_range and they are saved in sfp. Since a fingerprints range has already been loaded is does not change those stored in param.
3. The cost function method uses (arbitrarily? assuming both versions are the same?) the sfp version, not the param version.
4. The `param version is saved to disk along with trained parameters.
5. If the user opens the trained calculator, they get the param version of the fingerprints_range but the calculator had instead been trained to the sfp version. Thus, energies / forces do not match.

The quickest fix would be to just set the two versions equal even if something is already in the param version. This is not perfect since the calculator will now behave differently than the one it loaded. A better solution would be to propagate the new values of fingerprints_range into the first layer of the neural network coefficients so that the behavior is identical.

[andrew_peterson]

Saved fingerprints range bug fix.

This is a half-measure fix. See Issue #47; a better solution is possible.

→ <<cset 46470e415a11>>

[andrew_peterson]

I think we shouldn't spend time on v0.4 unless there's a need to.