Install prerelease versions of Toga's dependencies for testbed testing

[rmartin16]

Back when pygobject==3.50.0 was released, it broke existing releases of Toga. PyGobject had published a prerelease version of 3.50.0 that would have triggered this failure prior to general release (albeit, only 6 days sooner at most in this example).

So, this change simply lets us test Toga with prereleases of dependencies published to PyPI. At worst, I think the risk is small (assuming others see at least some gain) given this is easily revertable.

PR Checklist:

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[mhsmith]

I'm not sure about this, because it makes the testbed less representative of a real-world app. It could lead to a situation where Toga works with a pre-release but doesn't work with the stable release which people are actually using.

[freakboy3742]

I think I agree with @mhsmith. In my experience, publishing pre-releases is a pretty rare occurrence in the first place. Even when they are published, we'd have a very limited window where the pre-release would allow us to be a canary for backwards incompatibilities in another project - unless the pre-release was available for more than a week, we'd be unlikely to guarantee that we're even going to do a build with a pre-release.

Looking at the gbulb/pygobject example specifically - the pre-release was available for 5 days; yes, we would have been able to catch the problem on our 9 Sep dependabot run; but the response would have been the same - land the pygobject async patch, and push out a new release. I'm not sure the extra couple of days head start would have helped that much in that case.

On top of that, there's the question of how much we want to be a canary for other project's instabilities :-)

Thanks for the suggestion, but I think I'm going to close this one as a wont fix.