Allow building helper binaries for tests

[luser]

I've written a few crates that do process manipulation, and when writing tests I find myself needing a helper binary to run and manipulate. Three quick examples are read-process-memory, spawn-ptrace, and spawn-task-port.

I currently just put those helper binaries in src/bin so they get built as programs, but they're not intended for end-user consumption and don't need to be built except for test usage. It would be nicer if cargo had a way to build helper binaries for tests, like perhaps .rs files under tests/bin could be treated as such? Helper binaries should be considered a dependency of running tests, so they should be rebuilt as necessary before tests are run, but could be built in parallel with the tests themselves.

[alexcrichton]

Yeah I've also done this many times before too! Agreed it'd be nice to have a dedicated set of targets for this for sure.

[dwijnand]

In case the backlink isn't clear, there was an initial implementation proposed in #4846, but the reality is that fixing this is going to require an RFC.

[rbtcollins]

I would very much like this too - I ran into this writing an implementation abstracting across ulimits, which really needs new processes spawned on windows, where fork() isn't a thing. I'm probably willing to do an RFC, but haven't done that in this community before - can I get a pointer to the process, starting points etc.

[epage]

To summarize #4846, that added tests/bin as a while new target kind.

One solution is #2911: have the test binary behind a feature and running tests automatically activates it. A hacky workaround, for now, is to have a dev-dependency on yourself that activates the feature.

Another option, if the binaries are from another package, is artifact dependencies.