[RFC] Plan for PTR 3.0

[christiangnrd]

Looking for feedback on 2 breaking changes I've been considering recently.

• Setting a lower default memory_per_worker value. This is tchnically not breaking, but with how sensitive the low memory macOS runners are to these changes, I think it needs to be done in a breaking release so package maintainers using PTR can consciously try it out and tune the value (or set it back to the old default)
• Make the custom test worker interface extensible. A few features I've implemented would have been better implemented using the channels, but because the interface must stay the same for custom TestRecords (only used by CUDA?), I've had to extend the IO context struct which is a bit of a hack. Maybe passing those parameters as a dict would be easier to make extensible?

[giordano]

One thing is that we keep shoving more and more keyword arguments into runtests. I don't know whether we should consider a "config" object instead (but probably won't change much in practice for end users, it'd only allow us to have more structure)

[giordano]

Other crazy idea: expose to the user the recycling mechanism, so let them control it. One use case might be GPU systems, at the moment our recycling mechanism is exclusively based on the host CPU memory usage, but I was thinking that perhaps users may want to terminate workers if they're squatting too much device memory