Releases: health-checks, auto-rollback, gradual rollout and a/b releases

### Required Terms

- [X] I agree to follow this project's [Code of Conduct](https://github.com/heroku/roadmap/blob/main/CODE_OF_CONDUCT.md)
- [X] I have read and accept the [Salesforce Program Agreement](https://www.salesforce.com/company/program-agreement/)

### What service(s) is this request for?

runtime

### Tell us about what you're trying to solve. What challenges are you facing?

We should improve how code changes (releases) are rolled out with Heroku. We should consider adding:

* Healthchecks: Currently Heroku deems a dyno healthy once it has bound to `$PORT`. This is too simplistic since the app may not actually be ready to serve traffic by then
* Auto-rollback: We don't automatically fail a release and auto-rollback, even when the platform can determine that dynos running the new release are crashing
* Gradual rollout: We have three different mechanisms for rollouts. The standard common runtime behavior, Preboot in common runtime and gradual rollout in Private Spaces (PS). The PS behavior is often not gradual enough and causes latency spikes apps under load
* A/B releases and canary releases: For even more assurance and flexibility

For non-web dynos, we should also establish a healthcheck convention and support rolling deploys (currently non-web dynos don't support any form of gradual rollout)