fix: Skip problematic cyclic dev-dependencies

[Veykril]

Implements a workaround for #14167, notably it does not implement the ideas surfaced in the issue, but takes a simpler to implement approach (and one that is more consistent).

Effectively, all this does is discard dev-dependency edges that go from a workspace library target to another workspace library target. This means, using a dev-dependency to another workspace member inside unit tests will always fail to resolve for r-a now, (instead of being order dependent and causing problems elsewhere) while things will work out fine in integration tests, benches, examples etc. This effectively acknowledges package cycles to be okay, but crate graph cycles to be invalid:

Quoting #14167 (comment)

Though, if you have “package cycle” in integration tests, you’d have “crate cycle” in unit test.

We disallow the latter here, while continuing to support the former

(What's missing is to supress diagnostics for such unit tests, though not doing so might be a good deterrent, making devs avoid the pattern altogether)

[Veykril]

@bors r+

[bors]

📌 Commit 76fb73a has been approved by Veykril

It is now in the queue for this repository.

[bors]

⌛ Testing commit 76fb73a with merge 59b9cc1...

[bors]

☀️ Test successful - checks-actions
Approved by: Veykril
Pushing 59b9cc1 to master...

[Veykril]

Well, this obviously didn't work out as I expected. Not sure why I thought this would be a good solution, one does quite often crate dev-only dependencies in their own workspace (r-a is an example of that). Guess we'll need to be a bit smarter about this after all.