Implementation for email data type

[kgodey]

Problem

Users may want to store emails in their database and utilize functionality that is specific to email addresses such as validation and grouping. We should allow them to do so and implement this type appropriately in the backend.

Proposed solution

PostgreSQL does not have a built-in type to handle email addresses, so we will create a custom type that users can install if they want to use it.

Tasks that need to completed:

• Design for email data type #235
• Backend work for Mathesar email custom type. #409
• Implement filtering options for the email type #410
• Implement grouping options for the email type #411
• Frontend implementation for Email Mathesar type #255

Additional context

• Mapping DB data types to Mathesar data types #269
• Mathesar should not depend on custom types being installed. #403
• Controlled casting #127
• Infer column type two #135

[mathemancer]

Note that this is already implemented at the DB level, and reflects properly in SQLAlchemy. We just need to make it possible to work with from the Column API and have some agreement about how the type should be represented in the API. (I.e., varchar is shown as VARCHAR in the API, but email would be mathesar_types.email if we use the same method for retrieving the type representation.)

Do we want to continue using the DB name for the types in the API, or come up with some kind of mapping to make them look better in the API? One detail is that if in the dim future we supported a different DB backend, the DB names even for some of the non-custom types would potentially change in the API.

[kgodey]

I know some of this is already implemented, but I wanted to make a full checklist of what we need for this type to work properly.

I'll make a separate ticket for mapping types to the API, I think we'll need some way to map DB types to more human-friendly types.

[kgodey]

Closing this since all subtasks are done.