Implement CLUBB-MF functionality on trunk

[adamrher]

This issue is associated with the CPT to test / implement CLUBB-MF (MF = mass fluxes) into CAM, in coordination with JPL / UCLA & NCAR (@mikaelwitte, @JulioTBacmeister)

After meeting with @gold2718, it was decided that an efficient way to develop the CLUBB-MF functionality is to develop a minimally functional version that can be turned off, and merge it with the trunk ASAP. Since this code touches multiple CAM externals, as well as the CAM source code itself, Steve has outlined the steps required to close this issue:

1. Open issues describing the work on ESCOMP/CAM, ESCOMP/CLUBB, and ESCOMP/PUMAS.
2. Do the work necessary to implement the new scheme, at least partially.
3. When the code can be turned off, submit PRs for CLUBB and PUMAS.
4. When CLUBB and PUMAS have been merged and tagged, submit a PR back to cam_development.
5. The CAM PR should have a (probably single column) test to protect the new EDMF functionality.

Our thinking is that the FSCAM test will be the BOMEX IOP, and I will reach out to Steve for assistance in developing this test when the time comes.

I currently have forked / branches for ESCOMP/CLUBB (clubb_release_b76a124.clubb-mf) and ESCOMP/PUMAS (pumas_cam-release_v1.3.clubb-mf). These are branches of the tags currently pointed to in Externals_CAM.cfg in the latest cam tag (as of now, cam6_2_039). I have a forked branch of cam6_2_039 that points to these new externals (cam6_2_039.clubb-mf). Depending on how long it takes to complete these tasks, I may have to consider updating to a later cam tag to expedite the cam PR (Im not sure how burdensome it is to be a few tags behind, so please advise when appropriate).

Future issues will be associated with further developing the CLUBB-MF code, primarily major coding / testing milestones that the CPT group feel should be merged with the trunk.