`aspire destroy` says it removes volumes for Docker Compose environments, but it only runs `docker compose down`

## Summary

For Docker Compose environments, `aspire destroy` confirms that it will remove containers, networks, and volumes, but the current implementation only runs `docker compose down` without `-v` / `--volumes`.

This means named volumes created by generated compose resources, for example `WithDataVolume()` on PostgreSQL, are left behind after destroy.

## Repro

1. Create an AppHost with a Docker Compose environment.
2. Add PostgreSQL with a data volume.
3. Run `aspire deploy`.
4. Run `aspire destroy` and confirm the prompt.
5. Inspect Docker volumes.

## Actual behavior

The destroy confirmation says that Aspire will stop and remove all containers, networks, and volumes, but the compose-managed named volume still exists after destroy.

## Expected behavior

One of these should happen:

1. `aspire destroy` should call `docker compose down -v` / `--volumes` so the behavior matches the confirmation text.
2. If Aspire intentionally wants to preserve named volumes, the confirmation text should be changed so it does not claim that volumes will be removed.

## Source evidence

The confirmation text says volumes are removed:

- `src/Aspire.Hosting.Docker/DockerComposeEnvironmentResource.cs`
- `ConfirmDestroyAsync(...)`
- `Shut down Docker Compose environment '{environmentName}'? This will stop and remove all containers, networks, and volumes.`

The runtime implementation only appends `down`:

- `src/Aspire.Hosting/Publishing/ContainerRuntimeBase.cs`
- `ComposeDownAsync(...)`
- `arguments += " down";`

There is no `-v` / `--volumes` in the Docker Compose teardown path.

## Notes

The issue is important, as the volume could contain old passwords and the like, meaning a new deploy after `aspire destroy` might fail from credential mismatch.
It might also be a good idea to have a separate prompt to ask if the user wants to delete volumes, as it could be that they want to take the containers down, but not the volumes. This also means we might need a check in the `aspire deploy` to check if the volumes already exist, to warn the user if they do exist before a clean deploy)