Create IO library for less coupling and easier interfacing with FATES

Right now the subroutines/modules that are responsible for IO in CTSM are not very centralized. Most of it happens through [`ncdio_pio`](https://github.com/ESCOMP/CTSM/blob/master/src/main/ncdio_pio.F90.in) but, there are other important modules, and these modules also depend on a number of other, non-strictly-IO modules.

Creating an IO package/library/centralized set of modules would help with decoupling and would allow FATES to more easily use IO (via an interface, etc.) with more flexibility. This would also make FATES unit tests that use inputs much easier to create.

Some notes:

* the main IO module (that calls `pio`, the external parallel IO library) is [`ncdio_pio`](https://github.com/ESCOMP/CTSM/blob/master/src/main/ncdio_pio.F90.in)
- `ncdio_pio` uses some `shr` modules (this is fine)
- it also uses:
- `spmdMod`: for global variables like `masterproc`, `mpicom`, `iam`, etc.
- `clm_varcon`: for global variables like `spval`, `ispval`, `grldn`
- `clm_varpar`: global variables `numrad`, `nlevgrnd`, `nlevlak`, `nlevdecomp_ful`, etc.
- `clm_varctl`: control variables `single_column` and `iulog`
- `decompMod`: a few subroutines that are *only* used within `ncdio_pio`, however they essentially map one input argument into another
- `perf_mod`: `t_startf` and `t_stopf` - never actually used
- `fileutils`: does file IO things
- `array_utils`: method `convert_to_logical`, only used in `ncdio_pio`
* this is quite coupled but I think there are a few options to decouple things

@billsacks and @ekluzek thoughts? I have some ideas that could depend on ["abstractions" vs "concretions"](https://condor.depaul.edu/dmumaugh/OOT/Design-Principles/dip.pdf) for these variables and methods