I think this makes it easier to read type variables when they come from
flex/rigid vars with pre-existing names, just give them a number suffix
to differentiate them.
Even if there are no changes to alias arguments, and no new variables were
introduced, we may still need to unify the "actual types" of the alias or opaque!
The unification is not necessary from a types perspective (and in fact, we may want
to disable it for `roc check` later on), but it is necessary for the monomorphizer,
which expects identical types to be reflected in the same variable.
As a concrete example, consider the unification of two opaques
P := [Zero, Succ P]
(@P (Succ n)) ~ (@P (Succ o))
`P` has no arguments, and unification of the surface of `P` introduces nothing new.
But if we do not unify the types of `n` and `o`, which are recursion variables, they
will remain disjoint! Currently, the implication of this is that they will be seen
to have separate recursive memory layouts in the monomorphizer - which is no good
for our compilation model.
Closes#3653
Replaces the previously-used `DeferredObligations` structure used for
accumulating and then acting over ability obligations during module
solving in favor of just the `ObligationCache`. The `ObligationCache`
stays alive for the entirety of a module solving and provides a
convenient mechanism for answering obligation queries with a backed
cache.
countSegments and strSplitHelp check whether the length of the string is
strictly greater-than the length of the delimiter, skipping most of the
logic when this is not the case.
Changing the check to a greater-than-or-equal allows for the case when
the string and the delimiter are equal, giving the expected result of
["", ""].
The test ensures countSegments returns a count of two when the string
and the delimiter are equal. The expected result of Str.split in that
case is ["", ""].
