new api first draft

[masklinn]

• basic interface remains (kinda, now returns typed results)
• fully typed (maybe?)
• results are "dataclasses", trivially convertible to the old results through dataclasses.asdict
• add a Parser indirection which can be used to better configure matchers (including matcher strategies e.g. #95 lazy matchers) and caches
• simplify the parser (now matcher) protocol

[masklinn]

@jab @thiefmaster since you were apparently interested in a more idiomatic API, this is my starting point / current thinking. It is very much patterned after the idea of utility functions in front of a flexible (and hopefully reasonably compositional) pile of classes.

So the basic use should be the same as today (a small handful of functions performing standard tasks, just better named, and returning dataclasses instead of unspecified dicts), but the intermediate Parser object would provide users of the library with a lot more flexibility in terms of caching strategy, matchers, or even parsing.