The iterated_component_association grammar construct appears in Ada RM
in two syntactic forms: with iterator_specification and with
defining_identifier. This is now properly reflected in the GNAT AST,
while previously we had two defining_identifiers regardless of the
syntactic form.

Cleanup related to handling of iterated_component_association in SPARK.
Behavior of the compiler itself should not be affected.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

	* exp_aggr.adb (Two_Pass_Aggregate_Expansion): Expand iterated
	component association with an unanalyzed copy of iterated
	expression. The previous code worked only because the expanded
	loop used both an analyzed copy of the iterator_specification and
	an analyzed copy of the iterated expression. Now the iterated
	expression is reanalyzed in the context of the expanded loop.
	* par-ch4.adb (Build_Iterated_Component_Association): Don't set
	defining identifier when iterator specification is present.
	* sem_aggr.adb (Resolve_Iterated_Association): Pick index name
	from the iterator specification.
	* sem_elab.adb (Traverse_Potential_Scenario): Handle iterated
	element association just like iterated component association. Not
	strictly part of this fix, but still worth for the completeness.
	* sem_res.adb (Resolve): Pick index name from the iterator
	specification, when present.
	* sem_util.adb (Traverse_More): For completeness, just like the
	change in Traverse_Potential_Scenario.
	* sinfo.ads
	(ITERATED_COMPONENT_ASSOCIATION): Fix and complete description.
	(ITERATED_ELEMENT_ASSOCIATION): Likewise.