Think through the role of patch "itype" for FATES simulations

[ekluzek]

For FATES itype on the patch has been unset for most FATES cases, with the exception of FATES-SP mode. However, when new CTSM code is added that uses itype this might be a problem when running with FATES. So we need a way for CTSM to recognize that it shouldn't use itype when it's unset and abort in some graceful manner. In #2935 we set itype to ispval for all FATES cases with the hope that this would cause the code to abort in DEBUG mode because of bounds overflow.

However, there are instances where non bare-soil patches are queried with things like:

if ( patch%itype(p) > noveg )then
.
.
.
end if

or just general range checking on itype that won't be caught when itype is set to ispval (currently -9999). So it doesn't catch these cases and die with an error.

So in order to make this robust, it seems like we need to do things along lines like on of these options:

1. Check for itype == ispval and abort (probably needs to be done both at initialization and run-time)
2. Use a different pattern for checking for baresoil or ranges of itype, use a method of some sort?
3. Have the FATES/CTSM interface make sure that itype is set correctly each FATES time-step
4. Another option I haven't thought of?

Since itype is relied upon so heavily in CTSM outside of FATES, it's important to think this through and commit to an option that will allow the code to be robust. As it is if new CTSM code is added that relies on the use of itype it isn't guaranteed to be caught, and the debugging time to figure that out can be significant. With the downstream affect of others using buggy code and doing simulations can be really high. Whereas adding appropriate error handling will immediately point it out.

[samsrabin]

SE meeting today: We want to get rid of itype throughout the code because it's fragile. There's nothing itype can do that wouldn't be better handled as a PFT-specific parameter. See #3388.