Now that we have unspecialized lambda sets, we need to properly copy
their specialization variables when a module imports another modules'
ability store. I think it will be easier to ensure the correctness if
we distinguish between a "pending" ability store (which may contain
imports whose variables have not been added to subs yet) and "resolved"
abilities stores, which are what we care about for solve and later on.
There is a cost to this since `PendingAbilitiesStore#resolve` destroys
and collects all of the ability member data, rather than in-place
mutating as we did before. However, the resulting `AbilitiesStore` is
now much smaller, so the memory footprint will be better, and also
every field besides `ability_members` will be moved rather than copied.
`abilities_in_scope` is a buffer we use to keep track of locally-defined
abilities before we've fully resolved them. We do this because we
canonicalize ability members signatures before we've registered an
ability to the abilities store, and canonicalization of signatures must
report `has` bounds that don't reference abilities.
So, this buffer is more appropriately named `pending_abilities_in_scope`.
There is also no reason to export it, because it is only relevant
during canonicalization of type defs in a module.
Disallow cycles that pass through a non-function value. Since we
evaluate eagerly, having one such cycle means there is at least one path
in the program that (likely) has unbounded recursion. Of course we can't
be certain (halting problem), but it's very likely, and avoids stuff
like #1926. Also, mono (as it's done today) won't work if things in a
cycle aren't functions.
Closes#1926
