implement PostgreSQL-compatible interval type

[sploiselle]

This PR refactors interval to improve PostgreSQL compatibility.

Biggest changes include:

• Mixed intervals, (i.e. months and durations) which are required for Postgres support.
• Supports both SQL standard and PostgreSQL-style interval strings (1-2 3 4:5:6:7 and 1 year 2 months... respectively).
• PostgreSQL consistent behavior for DateTimeField ranges (INTERVAL '1-2 3 4:5' MONTH)
• Includes interval docs.

Note: I'm missing comprehensive unit tests, but will add those once I get a greenlight that the overall structure of this code looks good.

Quick addendum:

• Postgres treats interval as having month, day, duration. However, I kept our implementation more similar to its prior iteration which only tracks month and duration, and treats day as part of duration. I haven't dug into ways in which this could interact with TIMESTAMP math, but it doesn't cause any regression in our current behavior.
• In DateTimeField ranges, Postgres ignores the leading field (e.g. in MONTH TO MINUTE, MONTH is a noop). I instead let this define the most significant value to keep in the output. This seems useful but ¯_(ツ)_/¯--is very easy to yank out.
• The previous code referred to all time-like strings as intervals, but the syntax for PG compatibility is slightly different, so I've tried to change the name to reflect that there are multiple time-like syntaxes. This naming and error messaging could be improved on, and would love any pointers here.

[quodlibetor]

I haven't looked into the code yet, but re keeping days and durations in the same field: I believe that this should be the same for all of our times since we're UTC ignoring leap seconds, but when we start supporting timezones that have something like DST there will be a difference.

[quodlibetor]

I'm only about half way done but I thought I'd share the small things that I've got so far.

Overall this is looking amazing!

[quodlibetor]

🥇 oh boy.

You don't need to implement all my changes, but an explicit yup/nope would make it easier for me to think through what you have done/intend to do.

[sploiselle]

@quodlibetor just wanted to give you a quick thanks and let you know I'll implement all of these comments this week. Appreciate your guidance on all these points; lots of things I wasn't aware of/old habits from Go.

[sploiselle]

@quod_libetor Thanks for your patience on this. tl;dr I cleaned up everything you requested/didn't clean up anything we agreed to leave as-is.

Detailed notes:

• Added thousands of lines' worth of unit tests!

  The implementation of this one type is knotted and spread out enough that I would love any new test failures to create a very solid trail of crumbs. I was potentially overzealous in the number of tests, so I could be convinced to pare these down.

  • I wasn't sure where to put all of the tests for IntervalValue, so just threw them at the bottom of the file; lmk if those should go elsewhere.

• Availed to turn all comments into doc comments, which used more Rust doc idioms. However, there's a world in which I missed one or two. Please let me know if you see them.

• Availed to reorg src/sql-parser/src/parser/datetime.rs to put "more important" functions at the top.

• Added DateTimeFieldValue, which tracks the unit and fraction value in a struct. I considered having a field that controlled both field's sign, but that ended up being much fussier on reads (where people are less attentive).

• Added the ability for TIMESTAMPS to have the same flexibility in their TIME component as SQL Standard-style H:M:S.NS (link). This only added 20 lines of code, and wanted to get it done while I saw the opening. Sorry! I did add .slt tests for the case.

[quodlibetor]

💰💰💰💰💰💰💰💰