Bugs in crop phenology when running with a Gregorian calendar

### 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 c432b6d0721dfb5b05b5bd417d64c0aaad8aff84 (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:
https://github.com/ESCOMP/CTSM/blob/57175712e10e443f37818c81b8e14c956f28de34/src/biogeochem/CNPhenologyMod.F90#L2033

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.