WINDUP-156: Some simplifications to Iteration variable handling (implici...

...t iteration variable names)

## How it works after this?
Now, you are able to name only the variables you are going to use, otherwise they are going to be calculated using defaults. You have 4 options to write rules.

* The old one, specify everything: 
```java
.when(
Query.find(AbcModel.class).as("abcModels")
).perform(
 Iteration.over("abcModels").as("abcModel")
....
```
* Specify **only** the list **iterable** name. When this is used, the name for each iterated variable is calculated automatically in the Iteration class (there is a specific method that returns for the given list it's calculated name). Right now it adds suffix "_instance"
```java
Query.find(AbcModel.class).as("abcModels")
).perform(
 Iteration.over("abcModels")
...
```
* Iterate over the variable set having the given types inside
```java
Query.find(AbcModel.class).and(Query.find(SecondModel.class))
).perform(
 Iteration.over(AbcModel.class)
...
```


* Specify **nothing**, everything is called using the default names saved as the static finals in the Iterator. 
```java
Query.find(AbcModel.class)
).perform(
 Iteration.over()
....
```
## Rewriting the rules
I have rewritten all the rules. The **old style** is used only for the reporting rules that are using the variable name in the reports. The **3. style** is used everywhere it looked it fits. Otherwise, the **2. style** is used.
If this PR will be accepted, I will update our wiki also with this message.

## Tests
`mvn clean install` passed on this PR.

## Future simplification
I would like to rename Iteration -> ForEach, over() -> in(). Foreach.in("...") would made it clearer for the rules I came across, however didn't came across all the rules (it may not fit to some rules). What do you think?
If it is just "it" wouldn't that make it impossible to access iteration variables from parent stack frames?