Allow using `LocalResourceInfo` for `RunInfo` providers

[thoughtpolice]

I have a test that runs QEMU, which needs the swtpm daemon that is needed to emulate TPMv2 functionality in software. I got LocalResourceInfo working for such a case, and it works pretty great. buck2 test path/to:test works correctly by starting the daemon and then running QEMU (there could be slightly better docs for this, but overall it wasn't too bad.)

But now I can't just buck2 run path/to:test anymore, because the resources (socket files) don't exist before starting QEMU. This is particularly annoying in my case, because I do in fact want to do buck2 run so that I can e.g. interactively debug inside QEMU.

I see no reason why RunInfo can't also work similarly to ExternalTestRunnerInfo, in that it should have two new fields, local_resources: list[label] and required_local_resources: [RequiredTestLocalResource], though in such a case that type should really be renamed RequiredLocalResource instead.

[blackm00n]

It seems like something that could be done theoretically (though it needs refactoring since currently local resources are set up in BuckTestOrchestrator. Though it feels like something avoidable since RunInfo can just be a wrapper script which sets up the resource, runs the actual binary then releases the resource. Tests are different in a way that you can a bunch of tests buck2 run //... in parallel and their access to resource needs to by synced while it is expensive to setup/release resource for each test case.

[thoughtpolice]

I think the issue in my mind going that route is: yes that can work, but where's the reuse? With my existing setup, I already have a way of expressing this dependency directly through the providers in the build system, but now, suddenly, for a slightly different workflow I have to go and write an entirely separate codepath that repeats all this and then serializes it just so that I can keep parity between the two?

I think this is an issue where for bigger dev teams it won't be a huge issue because they can just write the wrapper script. But as a solo person when I see this I think to myself that this is just a simple (from the users POV) generalization of what already exists.