Prefix modules with something like 'CTSM' to avoid name collisions

In trying to include CTSM in WRF, we have run into name collisions. In this case, it is because WRF includes some old CLM code, and we plan to handle this by renaming the code in WRF. But this made me realize that this could be a potential issue in general. For example, we have a number of generically-named modules like 'fileutils'. If another model being linked with CTSM happened to have a module with the same name as one of CTSM's, with a subroutine inside that also had the same name, then there would be problems. Depending on the details, this either causes an error at link time (due to duplicate symbols) or causes the executable to silently be created incorrectly - where just one of the multiply-defined subroutines is used in all cases.

I propose that we rename all of our modules to have a common prefix like "CTSM". I realize that this will be invasive, but I think it's important to avoid issues down the line as other models begin to link to CTSM. It is also potentially important just within CESM: There could be subtle bugs arising from name collisions between CTSM and other components.

If others agree, we'll need to decide on:

- What prefix to use: `CTSM`, `Ctsm`, `CTSM_`, `Ctsm_`, etc. I'd probably vote for `Ctsm`, because it is easier to read a module name like `CtsmMyModule` than `CTSMMyModule` or especially something like `CTSMCNC14DecayMod.F90` - the long sequence of uppercase characters at the beginning of the latter is hard to parse. For what it's worth, I see that FATES prefixes its files with `Fates`.

- Do we want to rename all the files, or just the modules contained within them? The benefit of renaming the files is that it keeps file names consistent with module names, which could be helpful. The downsides are that it leads to longer and harder to read file names, and in the short-term it could cause more merge issues. (@ekluzek thought that our dependency-generation tool requires file names to match module names, but I checked and that is no longer the case.)

If we do rename files at this time, this would also be a good time to broadly introduce the new file naming convention laid out in #835 .