[Postgres] [Firewall]: Provide basic firewall in front of dedicated Postgres instances (IP whitelisting)

### 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?

Postgres

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

Heroku Postgres instances are exposed to the public internet. The only authentication required is a simple password. This goes against best practices established back in the early 2000s of protecting resources behind a firewall to the limited set of origins that need access.

Salesforce currently only offers IP-based restrictions to Postgres instances if you purchase the Private Spaces product. This is a 5x cost multiplier over the standard "public Heroku" pricing. It is out of reach for almost all organizations that use Heroku and puts Heroku at a disadvantage to AWS which has offered simple Security Groups since Day #1 of their RDS product line.

The most minimal feature that should be available is a DENY ALL rule with holes punched through for Dyno access to the Postgres instance. Heroku controls the IP range that the Dynos are deployed to, presumably using AWS's VPC functionality so this should be straightforward.

Users (admins) should then be able to whitelist specific IPv4 and IPv6 addresses/ranges for ingress from the outside world.

It is acknowledged that the nature of the Dyno framework will likely not allow Heroku to deny access to the Postgres instance from other applications than the one that is containing the Postgres instance (i.e. all Heroku apps, by all customers, will likely be able to reach the Postgres instance). This is not ideal but brute force password attacks from within the Heroku infrastructure seem to be less viable than from the outside world.

It is also stipulated that this feature request only applies to dedicated Postgres instances -- it's impractical/impossible to implement this for shared Postgres.