ectrans benchmark with precision selected at runtime.

[piotrows]

This draft PR aims at demonstration of the possible technical solution to the challenge of selecting precision of computations at runtime. In the current state, the proposed solution relies on the use of Ninja due to the preprocessing that affects module names at compile time. However, it seems ready for the first assessment.
Main code modifications are:

1. Introduction of #include "renames.inc" at the beginnig of all relevant trans library files. The renames file performs:
   a) definition of the compiler-dependent suffixization macro
   b) performs suffixization (e.g. with _sp or _dp) of all relevant symbols like module or standalone subroutine names, that would otherwise be duplicated if trans_sp and trans_dp are linked together
   c) renames parkind1 to ec_parkind
   d) replaces JPRB as JPRD or JPRM, depending on the version of trans library compiled at hand
2. Create stub ectrans module that imports actual routines from trans/external as submodules. aiming at modern Fortran importing. The ectrans module relies on the existing interface headers of trans/include/ectrans, slightly preprocessed to offer "MODULE PROCEDURE" if needed.
3. The benchmark program is augmented with a set of wrappers to setup_trans(0), dir_trans, inv_trans etc. that are imported by a a benchmark program instead of their legacy trans/external counterparts. The latter (apart from specnorm) are not even compiled directly, but only when embedded into ectrans_mod submodules. The wrappers are equipped with an extra argument that is being resolved at the wrapping level, so the original trans external routines are not modified in this respect. At the moment, the wrappers sit in the program directory to minimise mixing with the legacy trans code.
4. Minor technical adaptations, namely introducing JPRC to serve in assignments like a=1.0_JPRC were introduced to satisfy the needs of the NVHPC preprocessor, which apparently can't identify macro names being a part of such statement(s). On the occasion, JPRB was removed when imported but not used in several files.
   The code compiles and runs with GNU, Intel and NVHPC on Atos. This draft PR will be shortly accompanied by another PR that demonstrates subsequent execution of the SP and DP versions of ectrans. For clarity, this PR has been stripped of the layer that enables that.

[piotrows]

I am thinking perhaps it would be better to state MODULE SUBROUTINE rather MODULE PROCEDURE, since the interface needs to be repeated anyway inside of the external/*.F90 routines for backward compatibility.

[samhatfield]

@wdeconinck shall we delete these PRs as I don't think they are being actively worked on anymore?

[piotrows]

@wdeconinck shall we delete these PRs as I don't think they are being actively worked on anymore?

You are right, it is probably worth to delete PRs except the last one, which should still hold an added value, even tough it is most probably significantly outdated.

[samhatfield]

Even if the PR is closed, the work isn't lost, since we still have the branches :) I prefer to only keep PRs which have a realistic pathway towards merging.