Soundness of `proc-macro-srv` crate

When using rust-analyzer as a library[1], we've found it helpful to use the proc-macro-srv crate directly (rather than via the server binary).
Its API is not marked unsafe, but doesn't seem to be sound in the usual sense:

• at a high level, dlopen() a caller-provided filename can obviously be UB without extra-lingual guarantees, this can't be avoided
• there are some techniques (use of mmap) that are similar, but could be avoided by doing IO a different way

There are multiple reasonable approaches to safety here, e.g.:

• mark most of the crate crate "unsafe" (but this probably bubbles all the way up to main())
• keep the safe APIs, based on crate-level assumptions about the environment
• say "this is an internal detail, we're not interested in safety contracts"

If there's some consensus on what the maintainers want here, I'd like to document/implement that.

[1] https://rust-lang.zulipchat.com/#narrow/channel/185405-t-compiler.2Frust-analyzer/topic/Bundling.20proc.20macros.20with.20rust-analyzer/with/504826746

Start by reading the proc-macro-srv crate's public API and the dlopen and mmap paths described in the issue. Review the linked Zulip discussion and existing comments to determine whether maintainers want unsafe APIs, documented environmental assumptions, or an internal-detail designation. Done means the chosen safety contract is clearly documented or implemented consistently.