Handle VARCHAR data type in the backend.

[kgodey]

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

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

• Users can use the API to change a column to VARCHAR if it's possible to do so.
• Users can set and change the n (length) of a given VARCHAR column via a type_options field in the API.
• Automatic type inference during file import suggests VARCHAR when it makes sense to do so.

Additional Context

• 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.
• Implementation for this is partially complete (specifically the first and third items).

[mathemancer]

A few details:

• VARCHAR is essentially the default type for Mathesar at the moment.
  • You can always alter a column type to VARCHAR.
  • If we can't detect any other type (e.g., BOOLEAN), we always fall back to VARCHAR when suggesting types.
• What remains to do is to let the user set a VARCHAR length. We need to decide how we want to handle arguments to types in general in the API, since this also has implications for setting, e.g., precision of DECIMAL type columns.
• We should probably either avoid suggesting a length for VARCHAR columns, or suggest a very generous length. Because VARCHAR columns are varying-length (meaning we don't store n bytes for an m-length entry in a VARCHAR(n)-type column, where m < n), I'm skeptical we need to suggest it at all. There isn't really an advantage, unless the user specifically wants to avoid long strings for some reason (e.g., maybe they're worried that a downstream DB won't be able to handle a 5000-character string).

[kgodey]

I don't think we should suggest a length, just support the option if the user wants to set one.