Improve Docker DX

Currently, the CLI classifies instances as "local" (i.e owned and managed by the CLI directly), "cloud" (Gel Cloud instances, also can be managed by the CLI) and "remote" (an arbitrary remote Gel instance that can only be connected to). Many devs are accustomed to using Docker (and Docker Compose specifically) for local development, and currently the CLI handles those instances as "remote", which introduces unnecessary friction especially around authentication.

Here's what I propose we should do:

1. Teach the CLI to read `docker-compose.yml` and detect if it contains a gel container. The exact detection mechanism is TBD, but a consideration should be given to custom images based on `geldata/gel`.
2. If a docker-compose with a gel container is found, `gel project init` should ask if the user wants to use that as the instance for the project, and if so, link the project to the container.
3. For convenience `edgedb instance start/stop/restart` should alias to `docker compose start/stop/restart `.
4. `edgedb instance upgrade` _should_ work, but most of the work should be done in the Docker image entrypoint (I already have a PoC for this for a dump/restore flow).

Start with the CLI entry points for `gel project init` and `edgedb instance start/stop/restart/upgrade`, then inspect how Docker Compose services and Gel instances are currently represented. Define the detection and linking behavior for `docker-compose.yml`, including custom `geldata/gel` images, and use the existing Docker entrypoint PoC as context for upgrade behavior. Done means Compose-backed Gel instances are detected, linked, controlled through the aliases, and have a defined upgrade path.

Written by the indexing model from the issue text.