Cranelift patch files are painful to maintain

The cranelift backend contains some patch files in compiler/rustc_codegen_cranelift/patches/ and CI will fail when those do not apply any more. That's quite painful; sometimes patch files can be fairly easily edited by hand but when that is not possible it's non-trivial to figure out what to do here. I don't think we should subject ourselves and our contributors to this. Patch files are a terrible way of maintaining code variants. I don't mind cranelift doing this in their subrepo, but the moment this becomes relevant for rustc contributors I think we should have a higher bar.

Can't we do something less hacky? With Miri we are setting --cfg miri and then we can use that to disable or otherwise adjust code that would make standard library tests fail with Miri. Can't whatever code runs the standard library tests with cranelift set --cfg cranelift and then we do something similar? That would be a lot better than patch files, IMO.

Cc @bjorn3

Start by examining compiler/rustc_codegen_cranelift/patches/ and the CI path that applies those patches. Compare this with how Miri uses --cfg miri, then trace how the standard library tests are run with Cranelift. Done means a decided, maintainable approach is implemented and the relevant tests and CI no longer depend on fragile patch files.