Describe the bug
With the new Lezer parser, in domain there is ambiguity when a subtype statement follows a constructor or function statement that does not have a named return type.

This is because we ignore newlines and after the return type identifier, there is an optional return name identifier for functions and constructors. When a subtype statement follows, the next identifier could be either the start of a subtype or the end of a function/constructor output type.

It is ambiguous to Lezer which is the correct case and it ends up accepting it as the return name for the function/constructor, causing a parse error.

To Reproduce
Go to domain
Type:

type A
type B        
function f(A arg) -> B
A <: B

Observe error on last line

Notes
We've tried the following to fix this:

1. Adding ambiguity markers so Lezer uses GLR. This did not have any effect although we tried many different combinations of where ambiguity markers went.
2. Looking into insertsemi to see if the insertedsemi on newline would hint to Lezer that the new identifier belonged to a new statement after a newline. For some reason, this insertedsemi would be placed on newline, but removed and moved to following the ambiguous identifier once the identifier has been typed. This seems to do with acceptToken in Codemirror library.
3. Making domain newline sensitive. This was decided to be not worth it because it leads to requiring newlines, having to make special rules about newlines at the beginning of programs, and potential extraneous edge cases.