migrate region-maps to on-demand

[nikomatsakis]

As part of #40746, we need to migrate the region-maps into incremental. However, @cramertj's first effort (#40873) revealed that this is a bit more complicated than I thought at first. In particular the current regions are "whole-crate", but moving them to on-demand then introduces unacceptable dependency edges everywhere.

I think the overall structure that we want is that one does not request the "region maps" for the entire crate, but rather for a particular function or item (probably a body, though currently closures would share a region maps with their containing function).

This is made somewhat more complex by the fact that the RegionMaps construction code is quite old and a bit complex. It has for example a whole bunch of ref-cells that I think are primarily just an artifact of it being old -- i.e., the mutations should all be occuring during the construction phase, and not later.

Another complicating factor is the fact that we intern code extents to a small integer. Currently this interning is done globally (i.e., across all functions). I think it'd be fine, however, to do that locally (i.e., have a distinct vector for each function).

Each of the above complications can be refactored away -- probably! -- but it'll be non-trivial. It certainly makes sense to do this in phases. I'm not sure what those phases ought to be. Probably this:

• Purge the refcells -- use &mut borrows during middle::region::resolve_crate() and otherwise the data should be immutable. If this fails, we should figure out why and refactor accordingly.
• Once the refcells are gone, try to thread through an appropriate fn or body-id into every call, and restructure the data to be per-fn.
• Once that is done, we can actually break the region map structure to be built "on demand" and do the construction per function.

[nikomatsakis]

@cramertj are you still interested in tackling this job?

[cramertj]

Yes!

[nikomatsakis]

This was done in #41662