#469 Removed the creation of parsable_x90 files. Fixes #458.

[hiker]

This only addresses the removal of the parsable_x90 files (and therefore fixes #458, and part of #469).

The removal itself was quick, but it caused a bug in the filenames used for the .an files.

Originally, the PSyclone step would create a .an file based on the parsed parsable_x90 file, e.g. sci_null_preconditioner_alg_mod.2456263381.an, storing AnalysedX90 data.
After processing with PSyclone, a new analyse step will analyse the algorithm layer file and create a new .an file. In the example above, it created sci_null_preconditioner_alg_mod.3489817750.an

The hash value used is based on the .x90 file, and the difference is caused by the changes caused by removing the comments and invoke names while making the files parsable (so I would actually suspect if we had a x90 files without invoke names and without comments, we would hit the same bug).

When the step to make the files parsable was skipped, the hash code used for the two .an files was the same (i.e. the X90 analyse file of the x90 file, and the psy-layer file using the x90 has was identical), so the x90 .an file was considered to be a prebuild, and Fab tried to load this 'prebuild as AnalysedFortran (which then of course failed).

In order to avoid this, I have changed the way the file name for the .an files are created: I leave the suffix (.f90 or .x90) attached to the names, so we now get two files :

sci_null_preconditioner_alg_mod.f90.3489817750.an
sci_null_preconditioner_alg_mod.x90.3489817750.an

This makes is a lot easier to see where the files came from (in the original scheme there was only a difference in the hash, and you could not easily 'see' which one was which).

As a result, I had to modify some additional tests to accommodate this change in file names.

[hiker]

Note that I have compiled several LFRic applications without any changes required. The only effect for an existing build would be that the prebuilds are not found the first time.

[hiker]

@yaswant , @MatthewHambley , @Pierre-siddall , @t00sa - ready for review.

[MatthewHambley]

A question.

[MatthewHambley]

The code removed by this change handles the fact that keyword arguments may not appear before positional arguments in Fortran. Presumably this doesn't trip up fParser like it was feared it might, which is why it can be removed. However, it doesn't change the fact that it is syntactically invalid. Are there any safeguards in place to deal with fParser suddenly deciding to care about this? Are we relying on the fact that it will throw a syntax error and we will fix it then?