Can we get rid of the `lib.miri.rs` hack now?

[RalfJung]

We added some quite elaborate hacks in bootstrap and Miri to support ./x miri running standard library tests in Miri. This comment explains why:

            // This hack helps bootstrap run standard library tests in Miri. The issue is as
            // follows: when running `cargo miri test` on libcore, cargo builds a local copy of core
            // and makes it a dependency of the integration test crate. This copy duplicates all the
            // lang items, so the build fails. (Regular testing avoids this because the sysroot is a
            // literal copy of what `cargo build` produces, but since Miri builds its own sysroot
            // this does not work for us.) So we need to make it so that the locally built libcore
            // contains all the items from `core`, but does not re-define them -- we want to replace
            // the entire crate but a re-export of the sysroot crate. We do this by swapping out the
            // source file: if `MIRI_REPLACE_LIBRS_IF_NOT_TEST` is set and we are building a
            // `lib.rs` file, and a `lib.miri.rs` file exists in the same folder, we build that
            // instead. But crucially we only do that for the library, not the test builds.

Turns out this is problematic not just for Miri but for everyone who wants to run the test suite, so @bjorn3 is moving things around to avoid the underlying issue (#135937, #136642). Once that is done, we can probably get rid of the hacks in Miri.

[bjorn3]

Once that is done, we can probably get rid of the hacks in Miri.

Indeed. We first have to move the tests for all sysroot crates to separate packages though before we can remove any lib.miri.rs. Otherwise when for example libstd gets tested, it will still try to build a second copy of libcore and liballoc just like previously when testing libcore and liballoc themself.