Inline (explicit) and implicit tracing

[deliciouslytyped]

Proposal:
Variant 1: Explicit inline tracing
There should be a debug() "parser" and a .debug() method. These should both pass through the values going through them and yield information about the parser state out of band. This the goal is to allow tracing parser state at any interface between parsers.

What immediately comes to mind for yielding information is print(), but it's probably better to have a default implementation and allow the user to override with a callback which gets passed all availible state.

Perhaps the initial implementation should yield some manner of structure (e.g. a (parsername, stream, index) namedtuple, or something, don't ask me how to implement things like parsername yet :P) and have a default callback implementation, which .debug() defaults to.

#46 (comment) is a partial example of this.

Variant 2: Implicit tracing with filtering
It shouldn't be necessary to change your code to be able to debug it.
parsy doesn't really have an "engine" (afaik?) so I assume all parsers will need to be modified to support this mode;
Since the parsers and combinators are pure functions it should be possible to wrap them all in a debugger function that will trace their i/o when the user requests it. Since you aren't specifiying where to trace by inserting a .debug() snippet, there should be a way to filter trace output a bit. One way to do this might be based on the stream index, so one can specify which section of the text that is being parsed, to trace.

This would need a little extra integration to pass the outer parser context into .bind(), so the parser can decide if it needs to trace? #47

Perhaps for this variant, it is mostly sufficient to augment Parser?

A drawback here is that it increases overall complexity and might be adding some global (albeit orthogonal to parsing,) state (namely, the callback)?

Misc:
Variant 1 seems easier to do, but it may be ideal to have both variants.

Variant 2 filtering may also be useful for variant 1.