Fix template iterator

[HGuillemet]

To generate Java classes for different sets of template arguments, the Parser, in declarations(), makes a first pass without argument values during which it fills an infoList (in DeclarationsList) with the infos targeting instances of the template, then makes additional passes for each element in infoList, filling templateMap with template arguments founds in each info.

To pick these infos, it calls infoMap.get(name) which may return infos with several cpp names.
For instance for ptr<X> it could return an info with the following cppNames:
["ArrayRef<ptr<X> >", "ptr<X>"].

Then when filling templateMap, only cppNames[0] is checked, and its Type.arguments are used to fill the templateMap values. In the example above, we will end up trying to instantiate ptr<ptr<X> >.

I came across this problem when trying to understand a concurrent modification exception thrown by the parser when the infoList was modified when using its iterator.

This PR proposes to replace the infoIterator with a string iterator containing cpp names founds in info, but only those that match the name of the declaration being parsed (in normalized form).

Checked on existing presets, nothing changed in parsing results.

Only the first matching cppName in each info is considered. I think returning all matching names would be better, but this would require modifications in existing presets.

[saudet]

I came across this problem when trying to understand a concurrent modification exception thrown by the parser when the infoList was modified when using its iterator.

Could you provide an example of that?