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 have two concerns here:

1. The comment doesn't quite match the code, as the code only searches the top of the stack. I'm not sure if this was the desired behavior?
2. I'm somewhat worried that this could end up finding singleton frames. Would that be a problem?

I am still kind of 50/50 on whether this behavior is a good thing. I am somewhat concerned that rule-authors will not know what to expect out of this when writing a nested rule that could potentially. WDYT @lincolnthree ?