introduce CompileOptions, StrictEOF option

[kovacsur]

The current implementation is a bit too forgiving for our use case. The particular issue that brought this to light was that an XPath expression like

//foo,garbage

will be parsed without issues. I propose the changes in this PR so that such expressions can be optionally rejected, while maintaining backward compatibility.

New versions of public functions are introduced that take the newly introduced CompileOptions parameter, with a single available option for now (the one that we needed for the case above).

There is another PR in the xmlquery repo to go with this one.

[zhengchun]

Hello, thank you for this feedback.

The expression like //foo,garbage should be invalid, I hadn't considered this case before. I think we should return an error instead of maintaining compatibility. This way keeps the code simple and usable; Additionally, no code change or add are needed for the 'xmlquery' project.

[kovacsur]

Sure, that works, too, assuming no one depends on the current behaviour (which they really shouldn't). Working in a corporate environment has made me extremely cautious about breaking backward compatibility, so adding an easily extensible flag system seemed like the right way to go. For our specific use case, simply throwing an error for expressions like this is sufficient.