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?
I think I like the current approach better than that. What are the pros/cons of going to "it"?