computeSolarEventTime may yield wrong-day sunrise/sunset when input Calendar's TZ differs from calculator TZ

[guillerodriguez]

When the Calendar passed to SolarEventCalculator.computeSolarEventTime is in a timezone different from the one used to create the SolarEventCalculator instance, the calculator may return the sunrise/sunset time for the wrong calendar day.

Reproducer:

SunriseSunsetCalculator calc = new SunriseSunsetCalculator(
    new Location("40.7128", "-74.0060"), "America/New_York");

Calendar c = Calendar.getInstance(TimeZone.getTimeZone("UTC"));
c.set(2024, Calendar.MARCH, 10, 0, 0, 0);
c.getTimeInMillis();   // force the instant to be computed; see note below

System.out.println(calc.getOfficialSunriseForDate(c));
// Expected: 07:15 (NYC sunrise on March 10)
// Actual:   06:16 (NYC sunrise on March 9)

The getTimeInMillis() call here is used to ensure that the Calendar instance received by SolarEventCalculator.computeSolarEventTime is already in isTimeSet=true state; otherwise, the bug is masked.

Root cause: SolarEventCalculator.computeSolarEventTime calls date.setTimeZone(this.timeZone). Changing the timezone preserves the instant but moves the wall-clock day: 2024-03-10 00:00 UTC becomes 2024-03-09 19:00 EST, so the algorithm reads DAY_OF_YEAR for March 9.

Additionally, computeSolarEventTime probably should not mutate the caller's Calendar.

(I have a fix ready for this issue, but it depends on #47 and #49.)