Split OperatorsSuite into smaller test cases. Use jUnit native assertions, rather then Scala native assertions.

[anatoliykmetyuk]

In it's current form, the output of the test case is hardly readable - because there's only one test case. It's hard to understand what's going wrong from the output like:

There was 1 failure:
1) testBehaviours(subscript.test.OperatorsSuite)
java.lang.AssertionError: expectedAtomsAtEndOfInput=b required=

I propose to create several test methods for several set of cases (say, one for usual operators, one for optional breaks etc), and also make sure that each entry of the specification list can manifest itself in case of failure so that we see at once what specification rule have failed.

Also, on failure, a long exception is thrown, java.lang.AssertionError. Test frameworks like jUnit usually have their own means of doing assertions, and if it fails they usually output this fact in a more elegant way then an exception. So I think we should use jUnit-specific assertions rather then scala native assertions.

[AndreVanDelft]

I have updated OperatorsSuite; it satisfies my own needs very well. It suits both regression testing and progression testing (i.e. it flags unexpected bug fixes). When a behaviour case fails it is easy to run that in debugging mode. Still I am not happy with the internals of ScriptExecutor.handleContinuation, but it works well enough FTTB for all kinds of process expressions that we are using.