Add compose.yml for new apps

[aaronmallen]

Summary

Generates a compose.yml file when a new app is created with either the postgres or mysql database adapter, so users can spin up a local database with docker compose up without any extra setup.

Design choices

Why compose.yml instead of docker-compose.yml

The Compose Specification (which Docker Compose v2 implements) treats compose.yaml / compose.yml as the canonical filename. docker-compose.yml is still supported, but only for backwards compatibility with v1.

From the Docker documentation:

The default path for a Compose file is compose.yaml (preferred) or compose.yml... Compose also supports docker-compose.yaml and docker-compose.yml for backwards compatibility.

Generating new projects with the modern name avoids steering users toward a legacy convention they would eventually need to migrate away from.

Why the database has no password

The generated compose.yml uses POSTGRES_HOST_AUTH_METHOD: trust for Postgres and MYSQL_ALLOW_EMPTY_PASSWORD: "yes" for MySQL. A few reasons:

1. It is a local development starter, not a production artifact. Anyone deploying this stack to a real environment is expected to replace the file (or its credentials), which is the same assumption every framework starter makes.
2. Zero credential plumbing. A generated password would need to be threaded through .env, config/db.rb, and the compose environment block, and kept in sync across all three. Any drift produces a confusing connection error on first run, which is a bad first experience for a brand new app.
3. Not network reachable in a meaningful way. The container only binds to localhost, so the unauthenticated socket is not exposed beyond the developer's machine.
4. Matches the expectations of hanami db create out of the box. Users can run hanami new, docker compose up, and hanami db create in sequence with no further configuration.

closes hanami/roadmap/issues/27

[github-actions]

ℹ️ Optional job failed: Ruby jruby

[wout]

This is great! Usually I do postgres:postgres@localhost anyway.

[timriley]

Thanks @aaronmallen!

[timriley]

Two follow-up tasks: #415 and #416

[timriley]

I reverted this in 644e8ea. This turned out to be a much bigger problem to solve. We need to factor in how our db CLI commands invoke database-specific CLIs on the host machine, which Docker doesn't solve at all. We should think about this more holistically and take another run at it in a future release.