The logic related with cpl_scalars needs to be revisited

@billsacks @mvertens

I think following strict logic related to `cpl_scalars` needs to be more flexible.

https://github.com/ESCOMP/CDEPS/blob/deaaaca9eaaafbd2fe61102037dc0622ed475bf9/datm/atm_comp_nuopc.F90#L499C2-L517C45

Let's assume that we have a component that just ask u and v wind component from CDEPS. For this case, there is no need to add `cpl_scalars` to the export state. We do not have CMEPS or we are not asking for shortwave radiation etc. to interpolate with coszen option. So, nothing fancy in there. If we really want to be community data model than we could not impose these kind of application specific limitations.

BTW, This was working before restructuring CDEPS by setting `export_all = .true.` without connecting `cpl_scalars`. But now, if you set `export_all = .true.` then you need to set all the variables listed in the following part of the code even if the consumer component does not use them.

https://github.com/ESCOMP/CDEPS/blob/deaaaca9eaaafbd2fe61102037dc0622ed475bf9/datm/datm_datamode_era5_mod.F90#L240

Because now we are checking all those variables, we are getting error and CDEPS complains about field which are not listed in the stream file. We could link all those variables to some fake variable (let's say to u component of the wind) and get rid of this problem but that is just a workaround (or hack) and it does not look good. Anyway, I think we really need to think about this logic and flex it somehow.

I am always using CDEPS as a data provider in my GitHub runners to create very simple and realistic actions that test the NUOPC cap in an isolated way but now all those failing. I could create my own branch and put hacks to get around it but it would be nice to use CDEPS as it is without those limitations. Anyway, I am happy to discuss more about it if you would like.