shr_orb should not require components to have a hack in their time manager for leap years

[billsacks]

Currently, some subroutines in shr_orb_mod do not work correctly for leap years. As a workaround, CAM has the following in its time manager:

https://github.com/ESCOMP/CAM/blob/ce2e330303acc836a956d448f0e2e06d5c12821e/src/utils/time_manager.F90#L886-L898

and CTSM has something similar. The problems with putting this workaround in each component's time manager are that every component needs to be sure to implement this consistently, and the workaround ends up getting applied in situations where it shouldn't be. (The latter is what led us to discover the issue in CTSM; our plan is to only apply the workaround conditionally, so it is applied for some calls to get_curr_calday but not others.)

Based on yesterday's CSEG meeting, the proposed solution is to move the workaround into the appropriate subroutine(s) in shr_orb_mod itself, then removing this workaround from the components' time managers. So, within the components' time managers, Dec 31 on a leap year will give a calendar day that truly represents day 366, but then inside the shr_orb_mod subroutines this is converted to the previous day.

It is important that components remain consistent for (at least) two reasons:

(1) The calls to shr_orb_mod should be made consistently

(2) Surface components need to remain consistent with the atmosphere's (CAM's or DATM's) calculation of nextsw_cday; this is at least true for CTSM, where there is code like this:

https://github.com/ESCOMP/CTSM/blob/60b92b2711ff2e0a037d2049adf1a36a3a18ad48/src/cpl/nuopc/lnd_comp_nuopc.F90#L874-L875

so CTSM's internally-calculated calday should be done consistently with CAM's nextsw_cday.

So a proposed path forward is:

• Make the necessary changes in shr_orb_mod to translate too-large calendar days to day 365. This should be backwards compatible: if a component has already done the adjustment itself, then the new adjustment in shr_orb_mod won't do anything. This may result in changes for CICE (we're not sure), but shouldn't result in changes for CAM or CTSM.
• Change CAM, DATM, CTSM, CICE and any other needed components so that they no longer adjust calday internally, but instead rely on shr_orb_mod to do this adjustment.

If this plan isn't feasible for some reason, then an alternative is for @dabail10 to check CICE to confirm that it is doing its own adjustment of calday to be consistent with CAM.

@ekluzek @mvertens @gold2718 @cacraigucar @dabail10 @adamrher @olyson