A major change to what parameterization the parser combinators support:

The parser factor is no longer parameterized by a Type -- I realized that
it wasn't actually using the Type in such a way that other implementations
of Type (besides MaybeError) would be likely to work; in other words, the
implementation was still coupled to MaybeError.  I believe that it would
require heavy use of complicated functional constructs in order to correctly
abstract over the Type, which would probably complicate the code considerably.

Instead, I decided to explicity couple the implementation to MaybeError, so
that the code is no longer *lying* about what it supports.

At the same time, the combinators are now parameterizable by `item` -- the
basic parser that consumes a single token.  This was done because I recognized
two distinct, valid implementations of `item`: 1) just consumes a single
token, does nothing else; 2) consumes a single token but also tracks position
by counting line/column numbers.  Four other combinators -- `literal`,
`satisfy`, `not1`, and `string` -- directly depend on `item` and whatever
effects it brings along.

The implementations of these two `item` versions are placed alongside the
parser factory, and the `unparse.standard` module is responsible for actually
using the factory function to create the two separate parser classes.

The old code is now in `unparse.experiments`, along with a version that
eschewed the
class-based design in favor of free functions.  This had the advantages of
uniformity and simplicity, but the (arguably inconsequential) disadvantage
of not being able to use some of the combinators as method calls.  Perhaps
this will make a return soon.

In addition, there are two new combinators:
 - `catchError`, which is more fundamental than `mapError` and should
   probably be used to implement it
 - `lookahead`, which is the positive version of `not0` -- checks that
   a parser succeeds without actually consuming any input
unit tests for line/col-counting parsers
remove Type-parameterized combinators (class-based)
major parser overhaul:

function-based instead of class/method-based, because:
 - uniformity. Some of the combinators in the class-based version were static,
   in which case they'd be called like functions, while others were instance
   methods, in which case they'd be called through the `.<name>` syntax. Now
   everything is used the same way

reflect changes in tests
re-do example parsers to use new parser combinators
bump version number and add 'unparse.examples' package to setup
example:  nmrstar parser