Fix hashing

[ElliottKasoar]

• Fixes the hasher definition, as discussed in the issue.

  • I've removed the second creation of a hasher object, which means the overall hash is similar to the erroneous behaviour before, in that the structure hash contributes to the final hash.

• Also updates the deprecated utcnow, and tidies the code slightly.

Edit: hash_strucutre seems fixed in test_write_and_read, but actually I'm not sure the example in the issue quite works yet, so I'll leave this as a draft for now.

[ElliottKasoar]

Ah, so @stenczelt, while this does fix the hash_structure example currently in the tests, the example in the linked issue still fails, which must be because the (float) positions read in by ASE differ to the original random numbers:

  comparison failed. Mismatched elements: 8 / 9:
  Max absolute difference: 4.723046176380308e-09
  Max relative difference: 2.2429495787383598e-08
  Index  | Obtained   | Expected                     
  (0, 0) | 0.77395605 | 0.7739560485559633 ± 1.0e-10 
  (0, 1) | 0.43887844 | 0.4388784397520523 ± 1.0e-10 
  (1, 0) | 0.69736803 | 0.6973680290593639 ± 1.0e-10 
  (1, 1) | 0.09417735 | 0.09417734788764953 ± 1.0e-10
  (1, 2) | 0.97562235 | 0.9756223516367559 ± 1.0e-10 
  (2, 0) | 0.7611397  | 0.761139701990353 ± 1.0e-10  
  (2, 1) | 0.78606431 | 0.7860643052769538 ± 1.0e-10 
  (2, 2) | 0.12811363 | 0.12811363267554587 ± 1.0e-10

Since test_write_and_read only looks at integer positions, this doesn't get picked up.

Do we want to try truncating the precision used in the hash to try to fix this?

It feels slightly dangerous, but I'm not sure what the alternative is, unless we accept that this is a limitation.