incr. comp.: Access span information more carefully throughout the compiler.

[michaelwoerister]

Currently span information is accessed and copied rather haphazardly throughout the compiler which introduces lots of "false" dependency edges, because the span information is then never used or just used for error reporting. A few examples are:

• The code generating debuginfo for structs, enums, and unions fetches the def_span of the type in questions, just to throw it away again immediately.
• Queries collect spans from all over for possible cycle error reporting. In many cases these would not have to be access otherwise.
• MIR contains span information which is later threaded through to debuginfo, which forces us to have manual special casing for ICH computation depending on debuginfo being enabled or not.
• Type inference seems to pre-collect span information for error reporting. This information will not be used unless an actual error occurs.

I'm sure there are many other examples. Since spans are inherently unstable (adding a new-line somewhere will change all subsequent spans within the same file) this is a problem.

One possible solution would be to not store spans directly in the HIR and MIR (and other places) anymore but in a side-table that is part of the HIR map. Instead of a Span one would use and pass around a SpanId (which can just be a newtyped HirId or NodeId). Only when the SpanId is resolved to an actual Span, would we register a dependency on the thing the span originated from.

cc @nikomatsakis