Lexing is done by basic hand-written state-machines. Test coverage is pretty
good. Parsing is implemented via PLY (http://www.dabeaz.com/ply/), an SLR
parser generator. PLY modules are pretty old by now and might be replaced
when a real pull mode is implemented (for interactive mode).

The parsing modules were implemented to work on incremental inputs. However,
they do not currently run in pull mode, mostly because it was unnecessary to
run mercurial tests, and also because I understood too late how it needed to
be done. Assuming that PLY can run in pull mode, there should not be any
structural issues with the lexer. Sub-lexers were not thoroughly tests in
incremental mode though.

The grammar handles most mercurial tests. When using it in another context,
be ready to encounter the following issues:
- Asynchronous lists implementation is minimal. It is good enoug to run

mercurial tests, no more.

Several constructs (until, case) are not implemented.

Using reserved words in basic token contexts (command arguments) may be
unsupported. Several priority rules were added for specific words already.

Cygwin utilities are (not very reliably, see builtin.py) detected since they
already output in binary LF mode. CRLF to LF conversion is performed on other
external utilities.

Unit tests coverage is good for the lexer, medium on the parser and partial
for the interpreter. The latter relies on mercurial tests which are a pretty
good test in themselves.