Add Actions workflow to enforce Docker layer count for ecosystem Dockerfiles

## Summary

Introduce a GitHub Actions workflow that automatically checks the number of layers in each ecosystem Dockerfile (e.g., `npm_and_yarn/Dockerfile`, `bundler/Dockerfile`, etc.) in this repository. The workflow must run on every pull request, enumerate the existing Docker layers, and ensure that PR changes do NOT add any new layers to any Dockerfile. If a Dockerfile is modified and results in more layers than before, the workflow should fail (but the check should NOT be required to merge PRs).

## Motivation

Docker image layer count directly affects build performance and caching efficiency. This project has strict layering to optimize build times and cache utilization across its ecosystem Dockerfiles. Introducing additional layers may unintentionally harm performance. Automated checks will help maintain this standard without relying on manual reviews.

## Acceptance Criteria
- For each PR, the workflow:
- Detects all ecosystem Dockerfiles (`*/Dockerfile` in root or subdirectories like `npm_and_yarn/`, `bundler/`, etc.)
- Compares the layer count between the PR branch and the base branch (main/default)
- Fails if any Dockerfile has a greater number of layers in the PR than in the base
- Outputs results for each Dockerfile checked (display changed/new/removed layers)
- Does NOT block merging (non-required check), but should be marked `failure` if layers are added
- Provide rerun and debugging help for contributors
- Add documentation for this check to the developer docs (e.g., `CONTRIBUTING.md`)

## Implementation Notes
- You can use [`dive`](https://github.com/wagoodman/dive), [`docker history`], or any other tool/script that outputs Docker layer counts (in CI)
- Should handle multi-stage Dockerfiles, artifacts, and differences in base image layers
- If possible, exclude changes that only affect labels, metadata, or comments
- The workflow should only fail (not warn) when a _layer_ is added—other changes (edits/removal) are fine
- Provide code comments and explanations for maintainers

## Example file pattern
- `uv/Dockerfile`
- `helm/Dockerfile`
- `swift/Dockerfile`
- `bazel/Dockerfile`
- `composer/Dockerfile`

## Suggestion
- Use matrix strategy to test all Dockerfiles
- Consider reusing actions or scripts from other Docker layer analysis projects

---

Search results for Dockerfiles in this repo are limited to 10 results—ensure your workflow checks _all_ ecosystem Dockerfiles.

See examples in [GitHub code search](https://github.com/search?q=repo%3Adependabot%2Fdependabot-core+path%3ADockerfile%24&type=code).