Reduce GNU Compilation Warnings

[scrasmussen]

This PR fixes all but one set of warnings when building with GNU and using the standard level of warning flags.

The warnings fixed are summarized as:

• Deleted Feature: do loop bounds must be integers
• Integer to logical type conversion
• Redefinition of CCPP macro
• Function type mismatches from old NetCDF Fortran 77 interfaces

• w3emc library warnings because they don't use generic interfaces this is now handled in PR #1070

  The w3emc module commit is just a wrapper to the normal w3emc w3difdat and w3movdat functions but uses generic interfaces in a single file. This means the type warnings only are produced once when compiling the wrapper module, rather than in every file that calls w3difdat and w3movdat. This wrapper file module can easily be removed in the future if the w3emc library decides to move to generic interfaces.

This PR almost fulfills the GNU compiler part of the requirement "Code must compile without errors or warnings. Errors and warnings may not be suppressed, and the compiler warning level ("-W" options) must be at least the default one." as pointed out in UFS issue #1984. It also a step towards fulfulling the goal/requirement of no warnings from -Wall, as pointed out in #495.

[scrasmussen]

This PR requires CCPP-SCM PR#424

[grantfirl]

I think that this is a good opportunity to eliminate the dependency of CCPP on NCEPlibs. See https://github.com/ufs-community/ccpp-physics/issues/46

[grantfirl]

@scrasmussen Would it be too much of a pain to rebase this on top of the ufs-community/ccpp-physics ufs/dev branch? Same with #1049? The issue that this is addressing came from the UFS, so the solution should probably go in there first. If it's too much of an ask, we can merge into NCAR/main first. I'd rather see a different solution than the w3emc_wrapper, though, we should be able to eliminate the dependency on w3emc, which simplifies the changes here.

[scrasmussen]

@scrasmussen Would it be too much of a pain to rebase this on top of the ufs-community/ccpp-physics ufs/dev branch? Same with #1049? The issue that this is addressing came from the UFS, so the solution should probably go in there first. If it's too much of an ask, we can merge into NCAR/main first. I'd rather see a different solution than the w3emc_wrapper, though, we should be able to eliminate the dependency on w3emc, which simplifies the changes here.

@grantfirl sorry, had missed this message. Not too much of a pain at all, will get these rebased soon! Also, will have an incoming PR that brings in the functions used from the w3emc and puts them in a module that the physics will build. There then won't be a w3emc dependency and it uses generic interfaces so the warnings from the w3emc functions will all be gone.

[scrasmussen]

@grantfirl this PR has now been rebased to the latest on main

[grantfirl]

@scrasmussen Sorry, I wasn't clear. In addition to being rebased, this PR should be targeted to ufs-community:ufs/dev.