Improve design of streams handling with a base type that can be extended for details of the specific stream in question

#3561 brings in a redesign of streams handling that has a base type that can be used for each different extension of streams usage in the code. This makes the code more modular, removes duplicated code, puts the streams handling under a wrapper in case it changes, and makes it easier to add unit testing to stream type extensions since the base type has a stub for it.

The advantages are:
- Removes about 300 lines of duplicated code for each new instance of streams needed
- Isolates the details of stream handling into one place
- Allows updates in CDEPS stream handling to only require maintenance in one place
- Allows different implementations to be easier to handle (the situation we had with the MCT vs ESMF interfaces for streams)
- Allows us to add any error checking that should be done for all streams in one place
- Makes it easier to unittest the extensions on top of the streams base type
- The modularity improvement makes the code easier to read and understand
- The streams extensions look like the rest of the code in CTSM rather than bound up in the streams types and subroutine calls
- Updates the programming paradigm to a useful OO pattern with customizations only in the extensions
- Allows streams type extensions to exist in the relevant physics directory rather than under src/share_esmf