machine module should be auto-generated

[gold2718]

In order to both be able to check type compatibility and to be able to generate different type sizes for (e.g.) kind_phys, I think we need to standardize types and use aliases to be able to cross check without undue restrictions.

At the moment, the only flexible type I think we need is kind_phys which could default to REAL64 and could be specified on the ccpp_capgen command line (e.g., --kind_phys=REAL32).

machine.F90 would be auto-generated with a definition for kind_phys and translations to other names would be made in Fortran modules. for instance:

use ISO_FORTRAN_ENV, only: r8 => REAL64
use ISO_FORTRAN_ENV, only: kind_grid => REAL64

or

use machine, only: r8 => kind_phys
use machine, only: kind_grid => kind_phys

or

use ISO_FORTRAN_ENV, only: r8 => REAL64
use machine, only: kind_grid => kind_phys

The type checker would process use lines for either ISO_FORTRAN_ENV or machine and internally use standard Fortran types (e.g., REAL64 or REAL32).

[climbfuji]

Related to NCAR/ccpp-physics#194

[gold2718]

We should expand the capability of the capgen interface to include options for all the 'standard' CCPP physics kinds.
The CCPP Framework committee hereby declares all kinds used today in GFS physics to be considered 'standard' CCPP physics kinds.

[climbfuji]

@gold2718 just checking because I came across this issue today: we don't need this resolved for the transition to capgen.py, correct?