Restructure netCDF find modules to use modern import target

[islas]

TYPE: enhancement

KEYWORDS: netCDF, cmake, compilation

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
The current iteration of the cmake build uses the old-style of finding modules. This limits the usability of transitive properties as well as the native netCDF cmake build which provide imported targets.

See https://cmake.org/cmake/help/latest/manual/cmake-developer.7.html#find-modules for more information on module writing.

Solution:
Augment the output of the provided find module to supply an imported target that fully describes the netCDF library. Additionally, in rewriting how targets in WRF reference netCDF remove unnecessary linking to the library. Ensure the provided import target and flags of the find module matches the netCDF[-Fortran].cmake.in outputs verbatim thus emulating the native netCDF build for additional robustness.

LIST OF MODIFIED FILES:
M CMakeLists.txt
M cmake/modules/FindnetCDF-Fortran.cmake
M cmake/modules/FindnetCDF.cmake
M external/CMakeLists.txt
M external/RSL_LITE/CMakeLists.txt
M external/atm_ocn/CMakeLists.txt
M external/esmf_time_f90/CMakeLists.txt
M external/fftpack/fftpack5/CMakeLists.txt
M external/io_adios2/CMakeLists.txt
M external/io_esmf/CMakeLists.txt
M external/io_grib1/CMakeLists.txt
M external/io_grib1/MEL_grib1/CMakeLists.txt
M external/io_grib1/WGRIB/CMakeLists.txt
M external/io_grib1/grib1_util/CMakeLists.txt
M external/io_grib2/bacio-1.3/CMakeLists.txt
M external/io_grib2/g2lib/CMakeLists.txt
M external/io_grib_share/CMakeLists.txt
M external/io_netcdf/CMakeLists.txt
M external/io_netcdfpar/CMakeLists.txt

RELEASE NOTE:
Restructure netCDF find modules to use modern import target

[islas]

Requires #2056 and #2053

[amstokely]

I think it would be a good idea to use ecbuild's FindNetCDF.cmake as it will allow WRF to be used with ecbuild, which is very commonly used for managing cmake packages in the atmosphere science community.

[islas]

I think it would be a good idea to use ecbuild's FindNetCDF.cmake as it will allow WRF to be used with ecbuild, which is very commonly used for managing cmake packages in the atmosphere science community.

I think we had discussed that module in an MPAS context. My take is that there are a few outstanding issues with that particular module that make it unattractive to use. Most notably it deviates from the UniData netCDF target names, making it unable to be a drop-in replacement with netCDF's native CMake builds - as well as introduces two "standard" naming conventions for netCDF in CMake. Additionally, it doesn't look like it queries the library features which affect WRF compilation.