Implement the remaining unimplemented proc-macro APIs in the proc-macro server

Note: This will have to wait until after my token map rewrite.

We have no issue tracking this yet so I figured making a barebones one should be good for any discussions involved as it is already known that this is gonna be a difficult thing to do.

To describe the problem in simple terms, a lot of the API exposes state of the world to proc-macros, an example being asking for the source of a span. In rustc, this is fine as the proc-macro server runs inside the main rustc process, but in rust-analyzer, the server is a separate process that rust-analyzer communicates to via a a json RPC interface. This worked out fine so far as we only need to ask the server to expand a proc-macro with a given token stream and giving back the expanded one. To serve these unimplemented APIs otoh, we need to allow the server to communicate back to the client (rust-analyzer) to ask for certain information / properties about the program (and potentially in the future even ask about expanding macros which requires name resolution 😭). In theory, this should be straight forward but we might run into problems wrt the client-server architecture of the proc-macro bridge. That's the main open question to solve once this is being worked on.

We also need to be able to inspect our used spans after https://github.com/rust-lang/rust-analyzer/pull/15959, so that our syntax fixup stuff can continue working. That is we need to special case the span setting functions such that fixup IDs are not copied over resulting in removed code.

Blocked on https://github.com/rust-lang/rust-analyzer/issues/19205

Start with the proc-macro server architecture and the blocking issue #19205, then review the client-server concerns described here. Also inspect PR #15959 to understand the span inspection and syntax-fixup requirements. Done means the remaining proc-macro APIs work across the bridge and span fixup behavior continues to work.