Installation assumptions regarding types (and casting)

[mathemancer]

Related to #130

We currently have a few dubious assumptions built into our implementation. (I can call them dubious, since I made them 😄 ). Off the top of my head:

• The ALTER COLUMN behavior assumes we have our custom type casting functions installed, and won't alter a column's type without one.
  • This lets us put some guardrails on user choices, and keeps novice users out of trouble.
  • This would (in the future) let us give custom "Mathesar names" to types that are friendlier than, e.g., VARCHAR(63).
  • This might be overly constraining for expert users, since they won't be able to change the type in unsupported ways, i.e., they won't be able to change to/from an unsupported type, and they won't be able to change between an unsupported type "pair" (for example, we don't allow changing an email column to a boolean column).
• We assume that our custom types have been installed on the database.
  • This assumption is quite dubious.
  • This does allow us to move quickly with implementation
  • The process for installing the custom types on a DB is very quick, and non-destructive.
  • If the user wants to use Mathesar on a previously-existing DB, they may have no use for the custom types.
• We assume that the Mathesar installation on a DB isn't modified while the web service is running.
  • For example, we assume that the types installed on the web service and on the DB are synced up.

[kgodey]

I made a couple of issues to cover the first two assumptions, which I don't think we should be making.

• Column alteration should not require custom type casting functions. #402
• Mathesar should not depend on custom types being installed. #403

I think the third assumption is fine to make for now, given that databases are configured in the settings file and not dynamically. #403 might also address parts of it.

[mathemancer]

I noted a couple of details on the issues so they'll be visible for the implementer.