Simple `proc_macro::Span` operations should not require going through bridge

Motivation

This was mentioned in #149229 and since there doesn't seem to be a dedicated issue tracking this, I decided to make one.

Essentially, Span::join is a pretty key operation on spans: the very simple example of combining the open and close spans for a group to get the span of the whole group applies beyond groups to all sorts of parser implementations. The fact that this is not a trivial operation and requires going through the bridge means that it incurs a substantially larger performance penalty than you'd expect.

Potential Solutions

I decided to keep the problem statement intentionally vague to ensure that the solution set is large enough to allow compromises between performance and compatibility. It's been proposed that the solution to this is to make Span have a set representation across bridges, but this isn't actually necessary to solve this problem: we could, for example, represent Span as an opaque "source" ID and a start and end index. To actually get information about what the source represents, e.g. a file or macro call site, or a concrete line/column number, you would still have to go through the bridge. But, simple operations like joining spans could easily be done without having to go through the bridge.

Start by reading the proc_macro::Span::join operation and the discussion in issue #149229. Determine which simple Span operations currently cross the bridge and compare the proposed representations, including a source ID with start and end indices. Done means an agreed implementation direction that reduces bridge overhead while preserving access to source and call-site information through the bridge.