Recusive build validation is not user friendly

[jrray]

We had a user encounter a build failure due to a recursive build, but it would only happen in CI. The only happen in CI part is not the focus, but it contributed to user confusion and frustration.

In this particular case, the package being built "example" depended on a package "dep" and some but not all of the versions/builds of "dep" had an install.requirement on "example". So it was up to the whims of the solver if a working or non-working build of "dep" was selected for the build environment.

Then, the validation error merely says that the validation rule was violated without giving the user any help understand where the recursive problem comes from. Experienced users can study the build environment solution report to figure it out.

What would make this become a non-problem is to block adding the package being built "example" from being added to the solution when solving for the build environment, unless recursive builds are enabled with --allow-circular-dependencies. This is what BinaryPackageBuilder::with_allow_circular_dependencies claims but the allow_circular_dependencies field appears to be unused at this point. It disappeared in #911.

It would be a non-problem because the solver could work harder to find a build of "dep" that does not introduce a recursive dependency.

[rydrman]

From the meeting today:

1. remove the --allow-circular-dependencies flag altogether since it's not actually used at all anymore
2. propagate the recursive build validation setting into the solver so that the solver rejects recursive packages outright in the build env solve unless it's allowed by the spec
3. bonus if we can identify if the solve fails in a recursive build and suggest looking at the validation rule as a solution - maybe via a documented error code and/or miette help message.