Handle INTERVAL type in the backend

[kgodey]

This issue is to ensure that Mathesar can handle the Postgres INTERVAL data type.

As part of this issue, we need to ensure that:

• Users can use the API to change a column to INTERVALif it's possible to do so (this should already be complete).
• Users can set and change the precision and fields of a given INTERVAL column via a type_options field in the API.
• Automatic type inference during file import suggests INTERVAL when it makes sense to do so.
  • We could use something like https://github.com/oleiade/durations or https://github.com/wroberts/pytimeparse
  • Some work on this is complete, but there are probably improvements to be made in detecting durations.

Additional Context

• Implementation for duration data type #251 (parent issue)
• See PR Extend the v0/databases/'s types list to show both Mathesar and DB type information. #368 for code that calculates which types are allowed for a column.
• Inference PRs:
  • Controlled casting #127
  • Infer column type two #135
• See comments on Avoiding lossy type conversions during import #132 for conversation about inferring durations.

[kgodey]

Marking as blocked until backend work in #250 is completed because they're related and we want to make sure implementations are consistent.

[silentninja]

@kgodey Since the backend issues that block this issue have a PR, can I work on this or should I wait till the blocking frontend issues are sorted out.

[kgodey]

@silentninja I think it's fine to start work on this, it was blocked by backend work.

[mathemancer]

@kgodey I don't think we should add any parsing in python for this, since the libraries you mentioned are less featureful than the native PostgreSQL parsing. Both understand fewer strings. For output and viewing, I think we should actually use strings rather than the default python timedelta. Unless we have reason to work with these in python, that is. The reason is that the timedelta in python is quite broken (it can't do months or years or decades properly). By contrast, the native PostgreSQL INTERVAL can add a decade properly (including leap days and seconds, etc.). This means the user would see a different value in the UI than would actually be added under the hood for, e.g., a month.

[kgodey]

@kgodey I don't think we should add any parsing in python for this, since the libraries you mentioned are less featureful than the native PostgreSQL parsing. Both understand fewer strings. For output and viewing, I think we should actually use strings rather than the default python timedelta. Unless we have reason to work with these in python, that is. The reason is that the timedelta in python is quite broken (it can't do months or years or decades properly). By contrast, the native PostgreSQL INTERVAL can add a decade properly (including leap days and seconds, etc.). This means the user would see a different value in the UI than would actually be added under the hood for, e.g., a month.

@mathemancer and I discussed this during our check-in today and it sounds fine to me. The plan is to create a custom SQLAlchemy type to handle INTERVAL DB types.