Refactoring: anchored spans

[nikomatsakis]

Currently, we have Span, which has offsets relative to the start of "some file" (you have to know which from context) and FileSpan (contains the file). Offsets relative to the start of the file are bad because if you "see them", you have to be recompiled whenever anything in that file is edited that occurred prior to that span.

I would like to move to the anchored scheme used in salsa-rs/salsa#396:

• Span would be relative to the start of the enclosing thing (e.g., function).
• We can still have the BIR link to syntax nodes, but alternatively we can have the BIR (and validated IR, modulo Refactoring: remove the validated tree? #211) carry spans directly. Today the BIR links to syntax nodes because spans are absolute and we don't want to "see them". Linking to syntax nodes may be useful for fancier diagnostics, since we can get the "full detail" of what was parsed, and carry the span of every little piece easily (e.g., to distinguish the spans of individual keywords, or distinguish multiple syntactic sugars that create the same BIR). But of course it also makes it harder to generate BIR. We could plausibly do both -- have an optional link to a syntax node and a span. Choices!
• There is a AnchoredSpan that includes the file and offsets relative to start of file. This is used in diagnostics and other things that are "final outputs" from the compiler.
• There would be an Anchored trait for things that anchor enclosing spans (in fact, I added it in refactor fn signatures to have syntax nodes #210). You can convert a span to an anchored span by invoking span.anchor_to(thing), which is a method also added in refactor fn signatures to have syntax nodes #210.
• Anchored things either store an absolute offset or perhaps a link to another anchored thing (Box<dyn Anchored>).