Backend work for Mathesar email custom type.

[kgodey]

This issue is to create a custom MATHESAR_TYPES.EMAIL data type to handle email addresses.

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

• The type should be case-insensitive at the DB layer (currently it's not)
• Our custom type is named MATHESAR_TYPES.EMAIL in the API (currently it's lowercase)
• Users can use the API to change a column to MATHESAR_TYPES.EMAIL if it's possible to do so (this should already be implemented).
• Automatic type inference during file import suggests MATHESAR_TYPES.EMAIL when it makes sense to do so (this should already be implemented).

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 as noted above, it just needs to be verified.

[nishit-prasad]

Hello, I am new and learning Python/Django as I go forward. Can I take this up?

Will be reviewing docs and other stuff to get things going and started.

[kgodey]

@nishit-prasad This issue requires knowledge of Postgres custom types and SQLAlchemy, so it might not be the best issue if you're currently learning Python/Django. I'd recommend starting with something related to the Django code like #364

[mathemancer]

Regarding naming, the email type is currently residing in a mathesar_types schema that exists solely to hold custom type definitions and associated functions. I suggest sticking with that unless there's a really good reason to change. Note that if we want to use unqualified type names, we'll need to install each type in each schema unless we want to use an extension installation process. Further, if a user then creates a schema, we'll need to add the custom types, and all associated functions to that schema, etc.

Thus, the proper name for the email type is mathesar_types.email.

[kgodey]

@mathemancer I think that's fine, my main concern was namespacing. I'll update the issue.