Calendar API cleanup

[chipkent]

The calendar API is a key part of the time library that was never modernized. This PR cleans up the user-facing calendar libraries:

1. Use new Java time types as the primary types.
2. Consistently and intelligently name all functions and classes.
3. Add missing functionality.
4. Support user-defined business calendars.
5. Provide basic example calendars.
6. Remove python methods that are likely to result in poor query performance because of accidental use.
7. Support conversions to numpy business calendars.

Many of the above changes are breaking. The prior library in DHC was not popularized because this API rework had not been completed. Hopefully, this means the number of impacted users is small.

The underlying library has >90% test coverage.

The Calendar XML configuration format has been changed to:

 <calendar>
     <name>USNYSE</name>
     <description>New York Stock Exchange Calendar</description>
     <timeZone>America/New_York</timeZone>
     <default>
          <businessTime><open>09:30</open><close>16:00</close></businessTime>
          <weekend>Saturday</weekend>
          <weekend>Sunday</weekend>
      </default>
      <firstValidDate>1999-01-01</firstValidDate>
      <lastValidDate>2003-12-31</lastValidDate>
      <holiday>
          <date>19990101</date>
      </holiday>
      <holiday>
          <date>20020705</date>
          <businessTime>
              <open>09:30</open>
              <close>13:00</close>
          </businessTime>
      </holiday>
 </calendar>

[devinrsmith]

It's important context, but we are depending on the clock state in DateTimeUtils. I'm not the biggest fan of the static state in DateTimeUtils in-and-of itself, but I wonder if we should be persisting that stateful dependency here? Should clock be a member of Calendar?

[chipkent]

I'm not fully following this set of comments.

DateTimeUtils is the foundational layer. Calendar is built on top of DateTimeUtils. BusinessCalendar is built on top of Calendar. If Calendar has its own clock, separate from DateTimeUtils, it is just going to lead to user nightmare scenarios since we can't tell the user to just change the clock in a single place. Instead, they will end up with an inconsistent view of the world where they need to know multiple places they need to update to achieve consistency.

[jmao-denver]

The Python changes LGTM.

[deephaven-internal]

Labels indicate documentation is required. Issues for documentation have been opened:

Community: https://github.com/deephaven/deephaven.io/issues/3610