[DISCUSS] More extensive pre-release testing

### Is your feature request related to a problem or challenge?

- Part of https://github.com/apache/datafusion/issues/13648

Up to now, when we have made DataFusion releases, we have mostly focused on validated that DataFusion's own unit tests have passed, (see [dev/release/README.md](https://github.com/apache/datafusion/blob/main/dev/release/README.md)) but haven't tested the upgrade with other downstream projects (like ballista, ray, InfluxDB IOx, etc) until *after* we have release the code

This results sometimes in downstream users finding issues after release. Some recent examples
- delta-rs upgrade: https://github.com/delta-io/delta-rs/pull/2886
- https://github.com/apache/datafusion/issues/13481
- https://github.com/apache/datafusion/issues/13568
- https://github.com/apache/datafusion/issues/13510

### Describe the solution you'd like

I would like to improve the testing / release process for DataFusion releases to reduce the number of regressions found **after** release.

This would likely take the form of updating the [dev/release/README.md](https://github.com/apache/datafusion/blob/main/dev/release/README.md)

### Describe alternatives you've considered

One idea mentioned by @Omega359 and @andygrove on https://github.com/apache/datafusion/issues/13525#issuecomment-2496487538

> Upgrading our own subprojects (Ballista, Comet, DF Python, DF Ray) as part of the DataFusion release process makes a lot of sense to validate that the upgrade guide is complete.

### Additional context

_No response_

Start with dev/release/README.md and review the linked downstream examples, including Ballista, Comet, DF Python, DF Ray, delta-rs, and the related DataFusion issues. Determine how pre-release upgrades should be tested and document the agreed release-process changes in the README. Done means the process addresses downstream validation before release.

Written by the indexing model from the issue text.