Documentation

A NameShape is a substitution on Names that can be used
to refine the identities of a hole while we are renaming interfaces
(see RnModIface). Specifically, a NameShape for
ns_module_nameA, defines a mapping from {A.T}
(for some OccNameT) to some arbitrary other Name.

The most intruiging thing about a NameShape, however, is
how it's constructed. A NameShape is *implied* by the
exported AvailInfos of the implementor of an interface:
if an implementor of signature H exports M.T, you implicitly
define a substitution from {H.T} to M.T. So a NameShape
is computed from the list of AvailInfos that are exported
by the implementation of a module, or successively merged
together by the export lists of signatures which are joining
together.

It's not the most obvious way to go about doing this, but it
does seem to work!

NB: Can't boot this and put it in NameShape because then we
start pulling in too many DynFlags things.

Given an existing NameShape, merge it with a list of AvailInfos
with Backpack style mix-in linking. This is used solely when merging
signatures together: we successively merge the exports of each
signature until we have the final, full exports of the merged signature.

What makes this operation nontrivial is what we are supposed to do when
we want to merge in an export for M.T when we already have an existing
export {H.T}. What should happen in this case is that {H.T} should be
unified with M.T: we've determined a more *precise* identity for the
export at OccNameT.

Note that we don't do unrestricted unification: only name holes from
ns_mod_name ns are flexible. This is because we have a much more
restricted notion of shaping than in Backpack'14: we do shaping
*as* we do type-checking. Thus, once we shape a signature, its
exports are *final* and we're not allowed to refine them further,