refactor: Add internationalized metadata columns to `connectors`

[jshearer]

This is step #1 of closing https://github.com/estuary/animated-carnival/issues/58

This adds title, logo_url, short_description, and recommended to the public.connectors schema. It also modifies the live_specs_ext schema to remove the reference to open_graph, and add references to these new columns instead.

---

This change is 

[travjenkins]

Do we also need changes to the connector seeding stuff?

[jshearer]

Yup good point, added

[jgraettinger]

Noting also there's a big comment on this in 06_connectors.sql which could use some love / updates.

[jshearer]

So wait, in practice this means you want me to edit the existing migration that introduces the connectors table? That seems wrong... but I'll try it and see what happens!

Edit: We talked, and I understand the intent here more clearly: what are currently called migrations are actually the equivalent of source code for the control-plane. As such, you wouldn't want to edit your source code by writing diffs, you'd want to directly edit the code. The same is true here -- migrations should be an implementation details related to deployment, rather than the primary source of truth.

[jshearer]

Ok so I went back and made the changes "in place" on the existing schema definitions. I have a few questions:

• I noticed that the detail column on public.connectors is missing in the schema definition, but present in the database (I think? I couldn't actually check prod as I can't get into supabase dashboard)
• WRT the big comment about OpenGraph in 06_connectors.sql... should we just nuke it when we nuke the rest of the opengraph columns? The only thing it would say now is "these fields are manually filled out whenever we add a connector"
• We had talked about supabase having tooling to auto-generate diffs from code changes, but I'm not seeing that. Rather, it looks like their docs recommend calling out to a postgres diffing utility that needs to talk to prod in order to figure out what changed. Is that the best practice here? I imagine as time goes on and we need things like SOC2/audits, that'll become more and more of a no-no.

@jgraettinger