Race condition in DFTD3 may give crashes and wrong results

Checklist

• The issue remains in the development version of ASE.
• An minimal example is provided to reproduce the issue.

Summary

@BorisWasBezet noticed crashes from DFTD3 where the number of atoms did not match the size of the calculated forces. We are 99% sure this occurs due to running multiple DFTD3-enabled DFT calculations (with GPAW) in the same folder. It looks like DFTD3 uses a file interface to communicate with an external executable, and that different calculations end up using the same file names and overwriting the same file.

This will cause crashes when timing is bad and the calculations use a different number of atoms, but much worse it will cause wrong results when the number of atoms are the same.

Suggestion: A label keyword can currently be given to the DFTD3 constructor, the default is a fixed string. I suggest that the default is changed to be a randomly generated label, using one of Pythons modules for generating unique temporary file name. Some care must be used to make sure that stuff still works in parallel MPI calculations (either only the master should call the executable, or perhaps it is just as well that they all get different file names?).