Support for cloning databases and multiple databases within a single Supabase instance

The current hypothesis seems to be that multiple databases per instance would require deep changes to the components that built atop it, but perhaps these changes need not be as sweeping as one might think. I believe that, if done correctly, supporting multiple databases is essentially orthogonal to the functionality of all the other components, except for Studio and the management API, which would need to be updated with UI elements and backend for switching between databases and cloning/snapshotting (more on that below). PostgREST and the Supabase auth, storage and realtime layers all know how to deal with a single Postgres database, and are structured accordingly, leveraging tables and users within that database for their functionality. As far as I'm concerned, that trend should continue unabated. The key point here is to leverage Postgres' existing rich support for multiple databases and let the other components continue to build atop the single database model. …