Sort errors by location before appending them to the AST

[NathanReb]

This may seem like an unnecessary feature since the whole point of embedding errors is to allow reporting them all at once. This works with merlin but not with the compiler which will only report the first one it encounters.

You'll note I kept the List.rev that was added in #447 so that errors with the same loc will appear in the preserved transformation order. That shouldn't impact a lot of real life cases though.

This will help fixing #453 's tests as well.

Note that the cookies and checks error will still be appended before the transformation errors so they won't be displayed by the compiler if there is one transformation error, even though they may be located closer to the beginning of the file.
I'm happy to simply collect all such errors together, sort them and then append them to AST as one common batch of errors if you think this is okay and won't break anything.

[pitag-ha]

That does sound good to me, but I'm a bit out of context: Why do the errors get sorted badly in the first place? I'm expecting them to be added to the list of errors in the order in which they're encountered when traversing the AST. That might be a different order than the one you're suggesting, but it would make it coherent with what happens when there's no ppx transformation.

[panglesd]

I think the reasoning was that errors that happen in an earlier stage of the transformation process should be reported first. Since the OCaml compiler shows only the first error in the AST, that was a way to do that.
If that is not the case, that's not intended!

However, I think that's a good idea to sort the errors by location. It makes it easier to have the right order, and is another natural order for the errors. So, I'm in favor of this PR!

[NathanReb]

#447 introduced a List.rev on the collected errors. That's because errors were being appended to a list as they were collected, meaning it was in reverse order, first error collected was last in the list. As it allowed multiple passes to take place even though previous transformation may have failed, it made sense to try and get the errors in the correct order, or at least, in the same order as transformations were being applied.

In #453, we allow context-free transformations to raise without canceling all subsequent context-free transformations. It seems that the above mentioned List.rev messes with how errors are collected and accumulated in the context-free pass as it's been swapping the order of those errors which were previously correctly ordered.

At this point it's hard to predict how errors will be ordered and so I decided to sort them by locations because that's likely the most meaningful order. Does that sound good to you?