RFC: WIP: More detailed error reporting (report only failed positions)

This patch is more advanced compared to #100

The NoMatch class is made smarter and tracks the exact match errors.
With this design, reporting an error translates to printing the diagnostics of all failed subexpressions of a failed expressions.

For example, for `Sequence`, the `SequenceNoMatch` class collects
the failed expression as well as all previously matched (but failed) `Optional` expressions.

The naming of `*NoMatch` certainly introduces some redundancy in the class
names, however, without this measure I had hard time visualizing the
internal structure of the failed expression to be printed.

Open question:

- Is this desirable that in case of ordered choices, we could print not only the winning match but all matches that are equally possible, as in this example:

```
assert (
    "Expected '4' at position (1, 15)"
    " or "
    "'five' at position (1, 20)" in str(e.value)
 )
```

The advantage of this approach would be that a user sees all alternatives that are possible in cases like this. The cost: the implementation has to
control whether several `at position` strings have to be presented instead
of a single `at position` at the end of the inspection message.