Ban unstable variables

[SeanTAllen]

This PR introduces checks around variables and other unaliasing points, to reject programs which attempt to create variables whose capabilities are inherently unsound. The checks about compatibility of intersections have been moved to this check after investigation of the origin, as it is not needed for soundness, but this can be reinstated in the original location if helpful for engineering purposes.

Fixes #3931

Some generic code may still produce unsoundness after instantiating, but this change is hopefully a step-forwarding to introducing the necessary constraints.

[SeanTAllen]

I've opened a new PR for this as ponycheck goes boom with this change.

See .https://ponylang.zulipchat.com/#narrow/stream/190359-ci/topic/Breakage.20against.20main.20failures

[jasoncarr0]

This last fix avoids the crash, but it doesn't seem to always be the right behavior so I'll need more here. We can compare to Array.init, which requires ephemerality to make iso^^ impossible because of the subtyping. But some generics actually want to have iso^^=iso^, e.g. the issue in itertools. So most likely the consume_type will need to be split in two for the use case of generic reification to have the latter behavior.

Otherwise suppose we have a signature like:
map[B]({(A!): B^}): Iter[B^]
This is reasonable but if we instantiate B with (A iso^ | None) then we can't use a function which returns A iso^ since it will be stripped away and replaced with None.

On the other hand, Array.init requires the behavior that invalid capabilities are removed.

[jasoncarr0]

This is good to go as far as I can tell. Review could benefit by making sure there's no case missing from the tests.

[SeanTAllen]

I rebased this against main

[SeanTAllen]

Failing test is unrelated.