Minor refactor of better for desugar

[som-snytt]

Move the complex guards into the body of the case and use an if conditional to handle is better fors or legacy.

The list of enumerators is split into a prefix of aliases and suffix of remaining. The guards made this obscure. (Probably the prefix of aliases is not long, so taking the span is cheap enough.)

Make the duplicated code in the last case a more exact copy. (But don't bother to DRY it out.)

[KacperFKorban]

Thanks for the PR, but I'm hesitant to merge changes that are primarily stylistic.
Readability is very subjective, and every time someone does a style refactor, other people have to re-learn the code.

[som-snytt]

In this case, I think the guard conditions are objectively hard to read. (As I learned when I had to read them.)

The guard condition says dropWhile and takeWhile which is probably less inefficient than the use of span in the commit.

The existing guard might be more conservative when the new feature is experimental (and the rest of the condition is never evaluated), but presumably the feature is actually exercised now.

I think the readability argument carries more weight, but if you don't see the value, then feel free to ignore the PR.

[som-snytt]

I wished to say, if you feel that the potential benefit is outweighed by the work to review the change, please ignore the PR.

[KacperFKorban]

Ok, sure I can be convinced that this improves readability and doesn't change it that much from the spec.

My main concerns were just that (1) the structure of the code looks less like the structure of the spec now (2) I want to see myself (and other people that already know the code) time from re-learning the same code, just to do a small change/review.

Sorry for the long reply times.

[som-snytt]

I'll look at whether it reflects the spec. It's certainly an Oderskyism that code should structurally preserve its specification (looking at parser, typer).