Polymorphic version for different obs in obsop

[cd10kfsu]

This issue should be labeled as features.

@StevePny @sanAkel later I will probably need to create a polymorphic version to store different observation types for obsop.
The reason is that different SST files might be of different formats, and have different properties. As we add more obs types into Ocean-LETKF, it creates a lot of repetitive codes as shown in obsop_*

It should be possible to define

type, abstract :: t_obs
<properties>
contains
procedure(get_loc_) :: get_loc
procedure(get_obsval_) :: get_obsval
....

and we can then define

type, extends(t_obs) :: t_sst_g17_abi_obs
type, extends(t_obs) :: t_sst_h08_ahi_obs
type, extends(t_obs) :: t_sss_jpl_l2b_obs
type, extends(t_obs) :: t_adt_avisio_obs

[sanAkel]

You could do that @cd10kfsu or have a yaml file that can be read in. See this https://github.com/Goddard-Fortran-Ecosystem/yaFyaml from @tclune, @mathomp4, and others.

[gmao-cda]

@sanAkel Thanks Santha. Currently I will leave it as the current state.
Preparing a minimal sample model output from GEOSgcm for obsop test.

[cd10kfsu]

Create observers for those top-level obs:

• SST
• SSS
• profile
• radiance
• precipitation

[gmao-cda]

Follow obsop in GEOSFV3-LETKF