Remove automatic collection of return values for iterations

[bd82]

The iterations DSL methods (MANY/AT_LEAST_ONE and _SEP variants)
automatically collect the return values of all iterations and return an array.

This causes some problems:

• This still happens when a CST is produced but the results are never used.
• In the use case of embedded methods we still may end up collecting information that is not needed.
  perhaps even collecting an array of "undefined" values.
• This potentially unused capability comes as a performance cost:
  • See results of removing this behaivor from only MANY DSL method.
  

Need to investigate if anyone actually uses these APIs.
And if they will be removed also update relevant docs.

[bd82]

While it does not make much sense to collect the iteration results when building a CST.
It does make sense to re-use those results when using embedded actions.
It would also be more consistent with the behavior of other DSL methods such as OR.

Perhaps it would be possible to optionally collect the iteration results only in embedded actions mode?

[bd82]

After some more thinking I've decided to remove the automatic result collection completely because:

1. CST creation (mostly) makes the the iteration results irrelevant and CST creation would become the default in version 4+.
2. The automatic results collection can be useful when using embedded actions, but it is just a convenience, one can always manually collect the results.
3. Lack of flexibility - when it does not fit one still pays the performance overhead.
4. The performance overhead can reach 10% (Parser only) which is too much for a little convenience.

Conditionally enabling / disabling the results collection is likely possible but the added
complexity may not be worth it.

Keeping all the DSL methods as expressions (returns something) is also purer in a theoretical sense,
but the problem is being theoretically correct versus faster and simpler in the common case.

[bd82]

Breaking changes will be tracked in
http://sap.github.io/chevrotain/docs/changes/BREAKING_CHANGES.html#_4-0-0