Refactor validation function containers to get rid of using Actor as a wrapper of a validation method

[avpotapov00]

Currently, we store validation functions as Actor inside ExecutionScenario etc., but Actor contains additional information about the operation, defined by user, and logically has fewer limitations:

1. An actor can throw exceptions, while a validation function can't
2. An actor can have arguments
3. Fields cancelOnSuspension, allowExtraSuspension, blocking, causesBlocking, promptCancellation, isSuspendable of the Actor class makes no sense in case of a validation function. The only reason for doing this is that it's easier to use TestThreadExecutionGenerator, which has TestThreadExecution create(Runner runner, int iThread, List<Actor> actors,... method.

We can fix it in two ways:

1. To create a hierarchy like that: In that case, we can move to the interface all required fields for execution generation and easily pass a validation function or an actor in into TestThreadExecutionGenerator. But, for example, property isSuspendable always will return false in case of validation function, so it looks weird and redundant, especially because it is needed only for one place in code.
2. To create wrappers with all required properties for a validation function method and an actor to pass into the TestThreadExecutionGenerator. This approach requires minimum code changes and development time but leads to some amount of small object allocations (for wrappers). We need to measure whether this results in decreased performance.
3. To refactor TestThreadExecutionGenerator to make it able to create executions for validation methods too.

[avpotapov00]

I think the third approach is more correct in every sense, except for the case when we don’t have time for this

[eupp]

I think we eventually should refactor TestThreadExecutionGenerator. See, e.g. this issue #196 Let's collect all the problems with current implementation that we want to solve with the refactoring.