Move backtrace handling code to separate crate

[Yamakaky]

That way, third-party crates, like backtrace, could use the same code than the compiler. It uses things like std::io and std::env, so it should depend on std.
Waiting for #38165 before starting.

[retep998]

As soon as the old makefiles are finally gone (#39431) Rust will be able to switch to using the external backtrace crate from crates.io.

[Mark-Simulacrum]

I think in order to use the external backtrace crate we'd have to make it capable of compiling with no_std; cc @alexcrichton (owner of the crate). However, I'm not very clear on the specifics here.

[alexcrichton]

Discussed on IRC with @Mark-Simulacrum, the thinking here is:

• Add a no_std profile of compiling the backtrace crate, probably stripping out most of the APIs
• Probably make all functions unsafe requiring explicit external synchronization
• Likely twiddle with CFLAGS and such to make building in libstd appropriate

And otherwise land it!

[Mark-Simulacrum]

So I put up a trial run of a no_std backtrace-rs implementation (rust-lang/backtrace-rs#50) that technically compiles on macOS and x86_64, if probably doesn't work. After realizing that we'd have to vendor 2-3 new repos in order for this to happen today, we decided it's not time yet. As such, I'm unassigning myself -- but if anyone wants to take the PR and branch I put up and push it into completion that would be a good start for the future.

[mati865]

@alexcrichton has #60852 fixed this issue?

[alexcrichton]

Yep!