Check dev-dependencies for bevy/bevy-internal only in test builds

[Waridley]

This fixes a regression caused by #1875 where using bevy in [dev-dependencies] but not in [dependencies] (using, e.g., bevy_ecs instead) would cause derive macros to fail to compile in non-test builds.

[Waridley]

Wow, I had run cargo fmt, but then changed .map into .and_then and forgot to run it again and it barely pushed the line over the length limit 🤣

[bjorn3]

#[cfg(test)] is only set when the current crate is itself tested, not when any dependent crate is being tested.

[Waridley]

RIP... I knew something had to be wrong with this approach. Any idea how to make this work, then?

Admittedly my specific use case is a bit of laziness, and not depending on bevy is saving me less as time goes on and I decide I want to use more of bevy's features... but this seems like something that might surprise other users...

[NathanSWard]

Is it possible to add a test for this?

[Waridley]

While I originally said this is a regression, it's entirely possible I'm the only user this is affecting, and I don't see a way forward if it's not possible to know when [dev-dependencies] are being used in downstream crates. The workaround is just to either refactor your tests to use individual crates, or refactor your main project to use bevy. So I'm going to close this.

Although I have to wonder if Bevy is really the only crate that has to deal with this. It really seems like proc-macros need a robust way to refer to the crate they are generating code for...