Extend 'StringParser' for passing initial positions

[gfngfn]

This PR adds StringParser.run-with-initial-position, a variant of StringParser.run for passing the initial position of inputs.

   val run : 'a Char.t Parser.t -> string -> 'a ((Char.t parse-error) list) result
+  val run-with-initial-position : 'a Char.t Parser.t -> token-position -> string -> 'a ((Char.t parse-error) list) result

This will be useful for reporting exact positions where an error occurred during parsing, especially during parsing at the preprocessing stage.

[nyuichi]

What about adding an optional argument to StringParser.run instead of introducing a new function?
At present we have no consensus whether we should treat adding an optional argument as a breaking change, but IMO such a change is not very critical and can be included in a minor version up.

[gfngfn]

Yes, I have once tried to add an optional argument to StringParser.run at the first commit as you pointed out:

• 78e65bd

It is possible, however, that adding optional arguments cause a kind of critical breaking change, roughly because having optional arguments restricts partial applications using |> in some cases. Indeed, the commit above breaks regexp.satyg.

Although this is not the problem of optional arguments but that of the type given to |>, it seems safer not to add optional arguments for now IMHO.

[nyuichi]

Hmm, I understood the point.
But I'm still hesitant to merge this change in its current form for the following reasons:

1. I don't feel it is a rigid method to add run-with-foo along with run. If we want to add another parameter bar, we would need to add run-with-bar and run-with-foo-and-bar.
2. Providing this new function run-with-init-position is not essential. Since the StringParser module doesn't contain opaque types, users can (in theory) write their own version of run-with-init-position using functions provided by the Parser module. (Of course, I don't mean run-with-init-position is worthless, but I mean we will need to clarify the motivation for adding this function at the risk of (1)).

I should emphasize I have no strong objection (nor a pushing proposal of my own). But I'd like to hear comments from anyone and evaluate to what extent my concern matters in reality.