Smiles parser user state

FParsec allows a freely definable user state type to be associated with a
parser. An instance of the type is associated with the input to a parser to
provide additional context.

My user state keeps a Molecule* record to build up the final result of the parser,
along with some context state to keep track of ring closure labels. (I'm assuming
there's going to be a post-processing step to go through the ring closure labels
map and add the extra bonds.)

* A Molecule has a list of atoms and a list of bonds. Where a bond consists of the
indexes of the two atoms it connects and a strength.

Molecule.AddAtom adds an atom to the end of the atom list and bonds it to the
previous atom in the list using the given bond strength
Update the user state when an atom is parsed.

The >>= operator applies the given function to the result of the parser. So,
when an atom is parsed a function is called with the results of the parsed atom.
The function adds the atom, bond, and any ring closure labels to the user state.

The result of the parser is now just a load of units instead of all the information
about the atoms, bonds and ring closures wrapped up in a tuples...which I think
is fine, because it's the user state type that knows how to deal with that rather
than letting it outside of the parser.

The MoleculeParserTests have been reworked to test the user state instead of
the parser result.

'run' only supports parser functions with no user state. So to test the parsers
it now uses 'runParserOnString' which takes a parser, a user state, a stream name,
and a string input. (The stream name is used in error messages - for now it's
empty.)

Also, renamed the succeedsWith helper function to succeedsWithResult to avoid
confusion with the new succeedsWithState helper function. One asserts that the
parser succeeds and produces the expected result, the other asserts that the
parser succeeds and produces the expected user state.