Expand formalized testing of build scenarios with user-provided include paths

[robertbartel]

Make sure there is sufficient testing of build functionality for scenarios involving a user-provided include path for dependencies, such as UDUNITS2. Tests of varying degrees of specificity can potentially happen at multiple event levels; e.g., some tests are performed automatically with every PR, some tests are run nightly, some tests are run during the release process; etc.

This relates to #725. Today, an example was reported with UDUNITS2_ROOT set when generating the build directory with CMake, where (despite CMake seemingly finding the right include path) the build failed due to:

..../ngen/include/core/mediator/UnitsHelper.hpp:14:14: fatal error: udunits2.h: No such file or directory

As noted near the bottom of #725, there is probably a workaround for this (though that isn't well document, yet: see #886). But the progression of that PR demonstrated that it's easy to miss when a subtle difference (either in the build setup or the environment) could break build behavior. We would benefit from making sure this is well tested.

We should also make sure to account for similar situations with any other user-provided paths; e.g. NETCDF_ROOT.