Abilities can only be defined on the toplevel of a module. There is a
technical reason to this, which is that during type solving we must
introduce all abilities at the very beginning, and we need to make sure
ranks are correct. But there is a practical reason as well, which is
that nested ability definitions don't seem to be very useful.
Note that specializations can be nested, and are allowed to be. Also, we
can revisit this in the future. I just don't want experiments to break
right now because someone uses an ability in a nested scope where we
don't expect.
Closes#2878
Just a refactoring PR. This is useful because during canonicalization
we always process type defs first, then value defs. With abilities this
distinction continues to grow; in that case, we have patterns associated
with types that we want to process before patterns from values.
I was hoping to add nested datatypes into the language, but it turns out
doing so is quite tricky and not all that useful with Roc's current
compilation model. Basically every implementation strategy I could think
of ended up requiring a uniform representation for the data layout
(or some ugly workaround). Furhermore it increased the complexity of the
checker/mono IR generator a little bit - basically, we must always pass
around the alias definitions of nested datatypes and instantiate them
at usage sites, rather than being able to unroll aliases as we currently
do during canonicalization.
So, especially because we don't support polymorphic recursion anyway, I
think it may be better to simply disallow any kind of nested datatypes
in the language. In any case, Stephanie Weirich [seems to think nested
datatypes are not needed](https://www.cis.upenn.edu/~plclub/blog/2020-12-04-nested-datatypes/).
Closes#2293
