feat(api): add .delta method for computing difference in units between two temporal values

[cpcloud]

This PR adds a new API to temporal types, delta, that allows users to compute
the difference between two temporal types (times, dates, and timestamps).

This implemented for all the backends for which it was relatively
straightforward to get matching behavior out of.

Backends differ in many annoying and meaningful ways in how they implement this
operation:

1. Naming: datediff (MS SQL), date_diff (DuckDB)
2. Whether the inputs work on all temporal types or there's a separate function
   for each type: date_diff (DuckDB, MS SQL, etc) vs time_diff,
   date_diff, timestamp_diff (BigQuery)
3. The meaning of the order of operands. (ClickHouse follows subtraction
   order, DuckDB subtracts the first argument from the second argument)
4. Whether the unit is a string or magic identifier 'day' (ClickHouse) vs
   DAY (MySQL)
5. Whether the computation truncates the inputs and then computes the delta,
   or truncates afterward. (Trino and MySQL truncate after, others before)

Tests hit each of these cases.

Backends that support one or more of these operations:

1. BigQuery
2. ClickHouse
3. DuckDB
4. MS SQL
5. MySQL
6. Snowflake
7. Trino

Notably, postgres and oracle do not have functions for computing the delta between two temporal types in integer units.

• Postgres only has functions for computing the delta that return intervals
• Oracle has this blog post showing how to use advanced database features to implement support for this operation.

Closes #7195

[cpcloud]

Clouds are passing

…/ibis on  delta-api is 📦 v6.1.0 via 🐍 v3.10.12 via ❄️  impure (ibis-3.10.12-env)
❯ pytest -m 'bigquery or snowflake' --snapshot-update --allow-snapshot-deletion -n auto -q
bringing up nodes...
....x.....xx.x......x.x......xx..x...............x.......x.....x.x..x.x.x...............x.x...xx....x..x.....x....x.......x..x......x...x.......x...x.x..xx..x..x.....x.....x..x....x......... [  6%]
.xxx..x.x.x..x...x..x..x.....xx...............x.......x......x.............xx......x..x.......x.......xx..xx.........x................x....................x....x...............xx..........xx [ 13%]
.x.x....x.................x..........x...x.....................x.xx.x.x.............x.....x...x..xx....xx........x...x.......x.x...x.........x.s.............x..............................x. [ 20%]
s.......x..........x........................x...............x...x....x......xxxx......x........x......x....x.......xx.....x.x.x....x..x............x...x......x......x.................ssss... [ 26%]
x......x...xxx.....x.......x.x.xx.x....x.x.x........x.x....x..........x....................x.....xx.....x..x...............x.......xx..x.........xx.....xx..xx.x.x.x....x.x...x.xxx.x.x....... [ 33%]
.......x..x....x.xxxxx....x..xxx.x...x..xxx...sssss...xx.x.xx.x.xxxx.xxxx.x.xxx..........x..x.x.......xxsxx...xxxs......x...x...x..x...x...............x.....x.x.................xxx....x..... [ 40%]
.......x..............x...x...x....................x.x..x.x.................x..............x.....x.....................ss..........s....x..x..x....x..x.xx....................x......xx....... [ 47%]
....x...x......x.....x...x..x........ss.x.......x.....sx.........xx..x..x...x.x....x.................x.x.........x.......ss..x.......x..x..........x.x.x.....x......x...xx..x.xx.......xxx..x. [ 53%]
.........xxxxxx.....x.xx.xxxxs.xxxxxxxx...x.xx.xx.x.xxx.......x.x......x.x..........s.xx.xxxx....xx.......xx...........x...x.....x..x.............x.x..x....x.......s......................... [ 60%]
.....x..x.x............x.......x............x.x.......................................x........x.x................x.........ssss.............xx..x...........xxxxxxxx..x...................... [ 67%]
..............xx.....x.....xx....xx.x.x..x.x.x.....x...x...ss..x..x....x...x.....x....x........x.....xx.......x...x...............x......x.x.xx............s.x....x................x......x..x [ 73%]
.......x...x...x......x.........xs............................x.............................x.....................x...........................................................x...s..x........ [ 80%]
...x...xx..xss....x......x...........................x......xxx.xx....x.............x...................x.......x.............x................x.xx..x........................................ [ 87%]
.................................................................................................................................................x.............x.............................. [ 94%]
...................................x...................x......................x...............x...x..s.xxsx..........xx.................x........xx...............s...x.x                      [100%]
2353 passed, 38 skipped, 438 xfailed in 445.06s (0:07:25)

[cpcloud]

Just to show that the clouds are running the relevant tests successfully:

❯ pytest -m 'bigquery or snowflake' ibis/backends/tests/test_temporal.py::test_delta -vv
...
ibis/backends/tests/test_temporal.py::test_delta[snowflake-timestamp] PASSED [ 16%]
ibis/backends/tests/test_temporal.py::test_delta[snowflake-date] PASSED  [ 33%]
ibis/backends/tests/test_temporal.py::test_delta[snowflake-time] PASSED  [ 50%]
ibis/backends/tests/test_temporal.py::test_delta[bigquery-timestamp] PASSED [ 66%]
ibis/backends/tests/test_temporal.py::test_delta[bigquery-date] PASSED   [ 83%]
ibis/backends/tests/test_temporal.py::test_delta[bigquery-time] PASSED   [100%]

[gforsyth]

3. DuckDB subtracts the first argument from the second argument

WUT

Adding this one to the "SQL is everywhere" talk

[cpcloud]

This whole operation replaces TRIM as my go-to for things that look similar but are wildly different.

The temporal delta is a juicier example because there are multiple correct ways to implement it :)

[gforsyth]

This looks good to me -- one (non-blocking) question about the usage of _ in docstrings

[cpcloud]

@gforsyth I don't see your comment!