X.U.Parser: Achieve feature parity with ReadP

[slotThe]

Commit Summary

X.U.Parser: Feature parity with ReadP

While not many of these more exotic combinators are used right now, it's still nice to have feature parity (i.e., everything that one could want from a basic parser) such that people don't have to add their own combinators, in case they want to use one that's not already implemented.

X.U.Parser: Inline definitions

Most of these definitions are probably small enough to be inlined on their own, but tell GHC to try really hard regardless. This is commonly done by other parser libraries as well; e.g., 1, so it shouldn't cause any issues either way.

X.P.OrgMode: Remove pLast

Use the more aptly named option instead.

Checklist

• [x] I've read CONTRIBUTING.md

• [x] I've considered how to best test these changes (property, unit, manually, ...) and concluded: Pretty much all definitions are small and just what other parsing libraries do.

• [x] I updated the CHANGES.md file

[slotThe]

Except for the question of, if we're going for feature parity with other parsers, do we want to instead think about using one of them? Not saying we need to make that decision now, but we should consider whether we're just pointlessly proliferating parsers.

This is a good point, and I think it's worth thinking about it. I initially wrote X.U.Parser because ReadP, while being in base and pretty good for most use-cases, has quite confusing default behaviours for a lot of combinators. This is related to the difference between the truly commutative (+++), which is used basically everywhere, and the more parsec-like, left biased, (<++). I figured that we didn't want a dependency like megaparsec or attoparsec and the module was short enough (it's still not above 400 lines) that it didn't needlessly bloat the code base.