Update Atoms info from calculated results

[ElliottKasoar]

Initial work aiming to address part of #206:

• Ensure outputs from ase.io.write are consistent with singlepoint (i.e. results in info, they may or may not also be saved in calc.results)

Originally, I thought this would be implemented as a custom write function that also moved results to info, then called ase.io.write, but we want this even if we're not writing to file.

There's probably a better name than output_atoms, but the idea is a generalised version of what was previously done in single_point - move Atoms.calc.results to Atoms.info or Atoms.arrays, labelled with the MLIP architecture, and optionally delete the Atoms.calc.results value in the process.

To do:

• [x] More testing (possibly directly on the utils function) to ensure this behaves as expected, but so far seems to work with minimal changes
• [x] Extend to other calculations (currently only done for single_point and geom_opt, to give an idea of the changes required)
• [x] Update all CLIs (e.g. dealing with invalidate_calc, either as new option or via write_kwargs, since we don't return an Atoms object)

[oerc0122]

Following discussions, recommend developing separate script to automate generation of different MLIP records for database. That way files will only be read/written once and extra data appended to info object as it goes.

In terms of that, current implementation is fine provided non-arch key is also added so ASE automatically recognises the last run's parameters (this may want to be disabled in aforementioned script) as well as the tagged key.

Also suggest adding arch to the info block under the same grounds.

[ElliottKasoar]

With the last set of changes, this now:

• Includes an "arch" info label with the same tag as the labelled properties ([arch]_energy) etc.
• Defaults to both including both the info and original calc.results dicts
  • I don't especially like this, but losing the ability to use built in functions like Atoms.get_stress etc. by default seems really quite inconvenient at the moment

The current default of copying results to the info dict is still not obviously the right choice for me personally, but I think @alinelena disagrees.

[ElliottKasoar]

Relatively minor change to swap unpacking write_kwargs when it's passed to output_structs to passing it as the dict, as otherwise there could be keyword clashes e.g. from write_results.