Better deal with circular dependencies

[deivid-rodriguez]

What was the end-user or developer problem that led to this PR?

When a dependency includes a version with circular dependencies, and the resolver ends up considering it, it gives up with a confusing error.

What is your fix for the problem, implemented in this PR?

Ignore these ill-defined versions.

Fixes #6328.

Make sure the following tasks are checked

• Describe the problem / feature
• Write tests for features and bug fixes
• Write code to solve the problem
• Make sure you follow the current code style and write meaningful commit messages without tags

[deivid-rodriguez]

Spec added!

[deivid-rodriguez]

Actually let me try a slightly better approach.

[deivid-rodriguez]

Alright so the new approach is:

• If the self-referencing dependency is simply redundant, ignore the dependency but consider the version. This makes the case in Bundler: Could not find compatible versions for standalone_migrations + rack combo #6328 now resolve to the self-referencing version, which seems correct (2.0.4) since it's the highest one that meets all requirements.

• If the self-referencing dependency is incompatible with itself, then we completely ignore the version as a candidate for resolution. I've never seen such an ill-defined gem, but I believe it's currently possible to push such gem, so I handled this just in case.

We should probably raise a validation warning on gem build for the first case above, and an error for the latter.

[deivid-rodriguez]

I also proposed a similar change upstream.

[simi]

🤔 I can take over to introduce gemspec validations once merged.