Brief summary of bug

From some code inspection, I see what look like minor bugs in crop phenology when running with a Gregorian calendar.

General bug information

CTSM version you are using: latest master

Does this bug cause significantly incorrect results in the model's science? Maybe: I haven't thought carefully or investigated the magnitude of the impact. I suspect the impact is small, but I'm not positive about that.

Configurations affected: Runs with prognostic crops and a Gregorian calendar

Details of bug

I see two issues that look like bugs (though there may be others as well):

1. Some crops have a max_SH_planting_date of 1231. Normally get_calday will turn this into the value 365. However, if the run uses a Gregorian calendar, then get_calday uses a year of 0 for this date (because the general format is yyyymmdd, so 1231 implicitly has a year of 0); year 0 is considered a leap year, so get_calday actually returns a value of 366 for these crops. This is true with or without the Gregorian calendar "hack" that I just removed in c432b6d (since the value is exactly 366.0, that hack wasn't getting triggered for this value). I'm not sure what the implications of this are, but it seems possible that planting gets skipped entirely in some circumstances on non-leap years.

2. The calculation of days past planting:
   

   CTSM/src/biogeochem/CNPhenologyMod.F90

   Line 2033 in 5717571

   idpp = int(dayspyr) + jday - idop(p)

   uses the number of days per year in the current year. However, I think what's relevant here is the number of days per year in the previous year. (Imagine that it's now Jan 2, and planting happened on Dec. 30 of the previous year. Whether this year is a leap year is irrelevant; what matters for doing this day subtraction is whether last year was a leap year, and so whether Dec 30 was day of year 364 or 365 last year.) I haven't followed this through the code to see the impact of this issue, though my gut feeling is that it's probably relatively small.