Add ! mutation to INVERT_LOGICAL

[k3rn31]

To be done after #137

Add ! -> !! to INVERT_LOGICAL.

---

This is a little more challenging than the basic token mutations because Gremlins' mutator engine still doesn't support this kind of mutation where tokens are not simply swapped. In this case we have to wrap a unary operator into another unary operator.

[vsvastey]

Let me share some thoughts. They are not well structured yet, but anyway.

At the moment we have only token Mutant -- the mutant that changes token of the ast.Node.

To change the expression (and that is actually what we want for the ! -> !! case) we might want another Mutant, let's call it expression Mutant.

The main difference would be Apply method. Rather than replace token with another one, the expression Mutant would apply some function to the expression of a unary operator or to both expressions (separately for X and for Y, and maybe for both X and Y together) of a binary operator.

For ! -> !! case, it's quite obvious that we need to find NOT node and change its expression so that

exp = UnaryExpr {
	OpPos: curpos + 1 // ???
	Op : token.NOT   // NOT
	X: exp     // original expression
}

By the way, it might also be useful, to apply that mutation to binary logical expression, so that we would test not qust
a && b -> a || b
but also
a && b -> !a && b
a && b -> a && !b

[k3rn31]

Yes, the idea is to write another Mutant. My concern is to keep out from the Mutator as much mutant logic as possible. Ideally we should be able to implement a new Mutant without even touching Mutator.
Each Expr or Stmt can belong to more than one Mutant, that's why I think the "maps" system should be refactored so that the concrete Mutant is chosen from the Node and then it is its responsibility to get the correct mutant.Type and perform all the logic.
My points are:

• TokenNode instantiation should become part of TokenMutant, since it is specific to it and should not be instantiated directly by Mutator
• how can we decide on the concrete Mutant instantiation? Possibly avoiding a mega switch on all ast.Node possible cases? This can be complicated.
• how should the mappings be refactored? A map Stmt/Expr -> concreteMutant and the current mappings under TokenMutant?
• Since a mutant.Type can have mutation belonging to more than one concrete Mutant (as it it the case of INVERT_LOGICAL), how do we make this clear in the code?
• Is it correct that each concrete Mutant has to manage the concurrent locking? Wouldn't be better to wrap the actual mutation execution in a layer common to all the mutants?

I foresee a major refactoring of the relationship Mutant/Mutator, but I believe it is necessary and will open the doors to a lot of possibility on mutations.