do the `_unsynchronized` functions need to exist?

i found this comment in libstd: https://github.com/rust-lang/rust/blob/59a4f02f836f74c4cf08f47d76c9f6069a2f8276/library/std/src/sys/backtrace.rs#L20-L48

// Use a lock to prevent mixed output in multithreading context.
// Some platforms also requires it, like `SymFromAddr` on Windows.

and indeed dbghelp does not appear to be threadsafe. but backtrace-rs already has a mutex around dbghelp: https://github.com/rust-lang/backtrace-rs/blob/72265bea210891ae47bbe6d4f17b493ef0606619/src/dbghelp.rs#L283-L385
so i think it is not necessary for callers to have their own mutex? i do see that the gimli symbolification is unsafe because it accesses MAPPINGS_CACHE unsynchronized, but maybe we can use a similar trick there? or just use std::lazy or something? https://github.com/rust-lang/backtrace-rs/blob/dcd0aaa815a8f632a9febfc228cee61b4cc23bd3/src/symbolize/gimli.rs#L325-L339

see around https://github.com/rust-lang/rust/pull/127397#issuecomment-2211461065 for previous discussion; cc @ChrisDenton @workingjubilee

Start by reading libstd's backtrace.rs comment, src/dbghelp.rs, and src/symbolize/gimli.rs, then review the linked prior discussion in rust-lang/rust#127397. Compare the synchronization assumptions around the _unsynchronized functions and MAPPINGS_CACHE. Done means reaching a documented, maintainer-approved decision about whether those functions and their current synchronization model should remain.