Add overloaded rate law functions for Fortran90 - to reduce unnecessary DBLE() calls

[yantosca]

This PR modifies the rate-law functions in util/UserRateLaws.f90 as follows:

Each rate law function such as ARR:

   KPP_REAL FUNCTION ARR( A0,B0,C0 )
      REAL A0,B0,C0      
      ARR =  DBLE(A0) * EXP(-DBLE(B0)/TEMP) * (TEMP/300.0_dp)**DBLE(C0)
   END FUNCTION ARR

  ... etc ...

Has now been split into 2 rate-law functions: one that takes single-precision arguments and one that takes double-precision arguments:

  FUNCTION ARR_dp( a0, b0, c0 ) RESULT( k )
    ! Arrhenius function (dp args)
    REAL(dp), INTENT(IN) :: a0, b0, c0
    REAL(dp)             :: k
    k =  a0 * EXP(-b0/TEMP) * (TEMP/300.0_dp)**C0
  END FUNCTION ARR_dp

  FUNCTION ARR_sp( a0, b0, c0 ) RESULT( k )
    ! Arrhenius function (sp args)
    REAL(sp) :: a0, b0, c0
    REAL(dp) :: k
    k =  DBLE(a0) * EXP(-DBLE(b0)/TEMP) * (TEMP/300.0_dp)**DBLE(c0)
  END FUNCTION ARR_sp

  ... etc ...

This allows us to remove the calls to DBLE() in the functions that take double-precision arguments (which avoids unnecessary CPU cycles).

A new include file util/UserRateLawsInterfaces.f90 has also been introduced. This contains the INTERFACE statements that overload the separate single-precision and double-precision functions. These interfaces have to be placed into a separate file so that they can be inlined into the KPP_ROOT_Rates module file above the 'CONTAINS` statement:

  PRIVATE :: ARR_dp, ARR_sp
  INTERFACE ARR
     MODULE PROCEDURE ARR_dp
     MODULE PROCEDURE ARR_sp
  END INTERFACE ARR

  ... etc ...

Running C-I tests on this branch gives identical results to C-I tests run on the cleanup_int branch.

NOTE: I have the target branch for this PR as cleanup_int. After we merge this into cleanup_int we should be able to merge cleanup_int into dev.

[yantosca]

Hi @RolfSander and @jimmielin, I can add the other ARR functions but I thought let me just do the ones that were already present in the UserRateLaws.f90. I agree, we should rectify these. That might also require editing the sample mechanisms since some of them use ARR etc.

[RolfSander]

We could create a new branch cleanup_util for this purpose while continuing on the autoreduce merge at the same time?

[yantosca]

Cleanup_util sounds like a good idea