Provide an easy method to run the compiler and inspect SMIR

[celinval]

Most tools today that analyzes the MIR create some sort of rustc wrapper to compile the crate, and hook a callback to intercept the compiler execution and retrieve the MIR.

Let's look at a snippet of the existing stable MIR test: https://github.com/rust-lang/rust/blob/master/tests/ui-fulldeps/stable-mir/crate-info.rs

/// This test will generate and analyze a dummy crate using the stable mir.
/// For that, it will first write the dummy crate into a file.
/// It will invoke the compiler using a custom Callback implementation, which will
/// invoke Stable MIR APIs after the compiler has finished its analysis.
fn main() {
    let args = /* generate input test and args */;
    // Invoke rustc driver
    rustc_driver::catch_fatal_errors(|| {
        RunCompiler::new(&args, &mut SMirCalls {}).run().unwrap();
    })
    .unwrap();
}

struct SMirCalls {}

impl Callbacks for SMirCalls {
    /// Called after analysis. Return value instructs the compiler whether to
    /// continue the compilation afterwards (defaults to `Compilation::Continue`)
    fn after_analysis<'tcx>(
        &mut self,
        _handler: &EarlyErrorHandler,
        _compiler: &interface::Compiler,
        queries: &'tcx Queries<'tcx>,
    ) -> Compilation {
        queries.global_ctxt().unwrap().enter(|tcx| {
            rustc_smir::rustc_internal::run(tcx, || test_stable_mir(tcx));
        });
        // No need to keep going.
        Compilation::Stop
    }
}

Instead, we could provide StableMIR interface that does that for the user. I think for now it might be handy to provide access to TyCtxt, since StableMIR interface is not enough.

Maybe we could reduce this test to something like:

fn test_stable_mir(tcx: TyCtxt) {
}

fn main() {
    let args = /* generate input  and args */;
    // Invoke rustc driver
    let smir = stable_mir::StableMir::from(args).run(test_stable_mir);
}

This is just an example, and we may want to use a different pattern or encapsulate TyCtxt or any possible state we might want to keep.

BTW, this issue captures the initial work to encapsulate this boiler plate code that every driver has to implement, but
there are some things worth to keep in mind. We will likely want to provide some customization points to the user on arguments, logging, errors, and the MIR phase that is retrieved and whether it should be monomorphized or not.

[celinval]

@rustbot assign @ouz-a

One last try...

[ouz-a]

Can we close this now?