Use GreaterDate/DatePlusTTL rather than Unix Time

Fixes #47.

As a summary, this method is:
- Faster (doesn't spawn subshell and the external `date` command
- More accurate (y and m are now /calendar/ rather than 365d and 30d,
  respectively). Leap years are supported.
- More portable. This is POSIX compatible and doesn't rely on GNU or BSD
  specific features.
- More future proof. This code will handle dates past 2038 (epoch death)
  and prior to 1970 (not that the latter is needed).
- Fixes at least one known, unreported bug (snapshot name of
  2022-09-04_02.06.00--1y is silently skipped). This is likely due to
  an integer overflow.

Downsides are:
- We're maintaining our own understanding of dates now, which can get
  very ugly. However, the previous solution already had a very rigid
  definition of time. This solution is more correct -- albeit not 100%
  correct.
- Leap seconds are still not handled (I choose not to care; only 3 in
  last 10 years).
- The Gregorian Calendar is still required (likely to remain a hard
  dependency).
- We still don't handle time zones or DST. This should be fixed in the
  future, but will involve real effort to not break support for pre-TZ
  snapshots.
Don't accept/convert TTL of seconds w/o the 's'

The previous math is wrong, I doubt the feature is used much, and if it
is needed, a user can simply tack an 's' on the end, and it'll be
accepted, just not converted.