Add tests for different Fortran standards

[ElliottKasoar]

Aims to resolve #130.

From tests on my fork, it looks like there are a number of incompatibilities with the 95 and 2003s standards.

Some may be relatively simple to adjust for, particularly for the 2003 standard. For example, we use iso_fortran_env types that were not added until 2008, and in some cases variables have no IMPLICIT type.

The exact difference is obscured by fypp, but it appears there are significantly more issues for the 95 standard.

Given that I'm not aware of anyone encountering compatibility issues, stating support for 2008+ (e.g. similar to DL POLY) is perhaps the best first step, and arguably all we need to do.

Whether it's worth extending support for 2003 is probably best answered by people more familiar with the Fortran (HPC) ecosystem, but I'm generally wary of limiting access to newer features.

However, that's probably a separate PR anyway, so I'm happy to change the test matrix to 2008+ for now, and add a note in the requirements of the README accordingly if this sounds reasonable?

[jatkinson1000]

Discussion with @TomMelt We will set FTorch to require Fortran 2008 in the documentation.

@ElliottKasoar could you edit this PR to set the standard flag in the project CMake rather than as an extra flag in in the test suite?

To accompany could you edit the docs to specify F2008?

Thanks!

[jatkinson1000]

Thanks @ElliottKasoar

As per my previous comment we just discussed this and decided we should officially set the standard at Fortran 2008.

Please could you move the compiler flag to the the project CMake (we could allow users to override from the command-line as an optional build argument, but I don't think this is totally necessary to document) and add info as appropriate to the README and docs. If you feel really flashy we could have a shield: https://shields.io/ :P

[ElliottKasoar]

Sounds good to me.

Do you think it's still worth testing against more modern standards e.g. 2018, and potentially others in the future, or shall I drop the changes to the test workflow?

(I don't want to run the CI unnecessarily - the changes with 2008 + 2018 still in are here, ready to be cherry-picked, but I'm happy to just keep the README and CMake changes too).

[jatkinson1000]

Thanks @ElliottKasoar - Those additional commits on your fork look good to me.

I don't think it particularly harms to test 2018 - Fortran is famously backwards compatible, but an early warning if something goes astray would be useful. Ig you want to avoid unnecessary CI you could restrict 2018 to run only on merges to main. Depends how long it takes to run the job I guess.

Only other comment would be to check if the online documentation (FTorch.md or pages/) needs updating anywhere to match.

[ElliottKasoar]

Thanks @ElliottKasoar - Those additional commits on your fork look good to me.

I don't think it particularly harms to test 2018 - Fortran is famously backwards compatible, but an early warning if something goes astray would be useful. Ig you want to avoid unnecessary CI you could restrict 2018 to run only on merges to main. Depends how long it takes to run the job I guess.

Only other comment would be to check if the online documentation (FTorch.md or pages/) needs updating anywhere to match.

Great, I've left it more or less as it was in the branch I linked. The tests are only just over a minute each, which seems reasonable for now.

Good point about the online documentation. I couldn't see anything in either FTorch.md or the pages/, but I thought it made sense to add a similar dependencies section as we have in the README before the installation process.

[jatkinson1000]

Thanks @ElliottKasoar I'm happy with this being merged, thanks for the continued work!