`rtabort!` can panic on xous

We rely on rtabort to print an error message without calling untrusted code. If it is able to panic, several parts of the standard library become unsound due to disallowed reentrance into the global allocator.

Note that rtabort calls the platform's panic_output via rtprintpanic:

https://github.com/rust-lang/rust/blob/059bf4a660ddea5bd8302ecdd4f7e40dd7a04313/library/std/src/rt.rs#L40-L60

One of the panic_output implementations is in xous.rs:

https://github.com/rust-lang/rust/blob/059bf4a660ddea5bd8302ecdd4f7e40dd7a04313/library/std/src/sys/stdio/xous.rs#L111-L124

This calls into code with a lot of unwrap, expect, etc. calls in it, where it is unclear if they are meant to catch logic bugs or real failures from the environment. One concrete example that is probably from the latter category is std::os::xous::services::log::log_server unwrapping the result from std::os::xous::ffi::connect.
Note that its call literally has a comment on it saying it is "likely to succeed". That's not enough if failure causes unsoundness!

This should arguably never be touching unwrap or expect, since in this context they are equivalent to unwrap_unchecked, except without safety comments.

@rustbot label T-libs I-unsound A-global-allocator-reentry O-xous

Start in library/std/src/rt.rs at rtabort and rtprintpanic, then read library/std/src/sys/stdio/xous.rs at the panic_output implementation. Trace the unwrap and expect calls reached there, especially std::os::xous::services::log::log_server and its std::os::xous::ffi::connect call. Done means rtabort cannot panic when this platform output path encounters an environmental failure.