minicore: use the host's core when available

[tgross35]

From discussion at https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Using.20.60minicore.60.20for.20more.20compiletests, it would be ideal to replace minicore with the host's core if that is built. @jieyouxu pointed out that this did exist for the ABI compatibility test at some point adb6d47#diff-55f122dec36f78625c830ef254174f8ac89b16959557e11dff4d33ef9fd12438L70.

The main advantage here is it gives us a better chance of catching (unlikely) deviations between core and minicore, as opposed to always using minicore.

[nikic]

I feel like this would introduce a larger danger of writing a test that uses something that's not part of minicore (but is part of core). We'd still catch it eventually in a full bors run on a different arch, but this seems like an unnecessary footgun for the otherwise very reliable no_core tests.

[tgross35]

Something else loosely discussed on Zulip is that maybe minicore could be a file or module within library/core that can be built as a standalone crate. Then compiletest would use this directly and the real core just reexports things in the right place, so we'll always be using the same API regardless of whether or not all of core is available.

[jieyouxu]

I'm going to unassign myself for the time being because I don't know how to best approach this, since if a test is no_core... Does the test actually want a host core?

[jieyouxu]

Also opened #137531 to track how to check deviations between minicore / real core specifically

[Noratrieb]

I think I agree with nikic that using two different configurations seems more error-prone than just one.
Core deviating from minicore is definitely a concern, but I'm not sure it's that worrisome in practice, since significant deviations should hopefully be caught by tests suddenly failing.

[RalfJung]

I agree as well, we shouldn't use two different versions of this for two different configurations. So let's close this in favor of #137531.