Bad logic statement in strdata_interface_mod.F90

Description of the issue:

@matt-long tried to add a new forcing field to MARBL and have POP read it in through shared stream, but logic in strdata_interface_mod::POP_strdata_type_match() caused POP to ignore the fact that the field was in a different file and instead was appending the new field to the list of variables read from the stream providing NDEP forcing (which is bad, because the new field doesn't exist there).

Basically,

    POP_strdata_type_match = &
      strdata_input_var1%file_name     == strdata_input_var2%file_name  .and. &
      strdata_input_var1%year_first    == strdata_input_var2%year_first .and. &
      strdata_input_var1%year_last     == strdata_input_var2%year_last  .and. &
      strdata_input_var1%year_align    == strdata_input_var2%year_align .and. &
      strdata_input_var1%depth_flag .eqv. strdata_input_var2%depth_flag .and. &
      strdata_input_var1%tintalgo      == strdata_input_var2%tintalgo   .and. &
      strdata_input_var1%taxMode       == strdata_input_var2%taxMode

is returning True even when strdata_input_var1%file_name and strdata_input_var2%file_name differ. It looks like the solution is to wrap each individual logical statement in parentheses:

    POP_strdata_type_match = &
      (strdata_input_var1%file_name     == strdata_input_var2%file_name)  .and. &
      (strdata_input_var1%year_first    == strdata_input_var2%year_first) .and. &
      (strdata_input_var1%year_last     == strdata_input_var2%year_last)  .and. &
      (strdata_input_var1%year_align    == strdata_input_var2%year_align) .and. &
      (strdata_input_var1%depth_flag .eqv. strdata_input_var2%depth_flag) .and. &
      (strdata_input_var1%tintalgo      == strdata_input_var2%tintalgo)   .and. &
      (strdata_input_var1%taxMode       == strdata_input_var2%taxMode)

behaves as expected.

Version:

CESM: this is probably in every version of POP containing strdata_interface_mod.F90; I can track down exactly when this was introduced, but I think it was in the CESM 1.5 or CESM 2.0 development cycle.
POP2: We should definitely update main and the POP branch for CESM 2.1; it probably makes sense to patch CESM 2.2 as well, since that's the latest release.

Machine/Environment Description:

This was discovered on cheyenne in CESM 2.2, building with intel

ESCOMP / POP2-CESM