proc_macro/bridge: use the cross-thread executor for nested proc-macros by mysto...

While working on some other changes in the bridge, I noticed that when
running a nested proc-macro (which is currently only possible using
the unstable TokenStream::expand_expr), any symbols held by the
proc-macro client would be invalidated, as the same thread would be used
for the nested macro by default, and the interner doesn't handle nested
use.

After discussing with @eddyb, we decided the best approach might be to
force the use of the cross-thread executor for nested invocations, as it
will never re-use thread-local storage, avoiding the issue. This
shouldn't impact performance, as expand_expr is still unstable, and
infrequently used.

This was chosen rather than making the client symbol interner handle
nested invocations, as that would require replacing the internal
interner Vec with a BTreeMap (as valid symbol id ranges could now be
disjoint), and the symbol interner is known to be fairly perf-sensitive.

This patch adds checks to the execution strategy to use the cross-thread
executor when doing nested invocations. An alternative implementation
strategy could be to track this information in the ExtCtxt, however a
thread-local in the proc_macro crate was chosen to add an assertion so
that rust-analyzer is aware of the issue if it implements
expand_expr in the future.

r? @eddyb