duplicate attribute introduction

[jvoigtlaender]

The files examples/should_have_same_outcome/order_of_addAttribute/firstInSubClass.xml and examples/should_have_same_outcome/order_of_addAttribute/firstInSuperClass.xml are both deemed invalid here. In contrast, XModeler rejects one of them but not the other.

Note that on the xml file level, they differ only in the following way:

xmodeler-tooling/examples/should_have_same_outcome/order_of_addAttribute/firstInSubClass.xml

Lines 30 to 31 in ac0b921

	<addAttribute class="Root::ord::B" level="0" multiplicity="Seq{1,1,true,false}" name="attr" package="Root::ord" type="Root::XCore::Integer"/>
	<addAttribute class="Root::ord::A" level="0" multiplicity="Seq{1,1,true,false}" name="attr" package="Root::ord" type="Root::XCore::Integer"/>

vs.

xmodeler-tooling/examples/should_have_same_outcome/order_of_addAttribute/firstInSuperClass.xml

Lines 30 to 31 in ac0b921

	<addAttribute class="Root::ord::A" level="0" multiplicity="Seq{1,1,true,false}" name="attr" package="Root::ord" type="Root::XCore::Integer"/>
	<addAttribute class="Root::ord::B" level="0" multiplicity="Seq{1,1,true,false}" name="attr" package="Root::ord" type="Root::XCore::Integer"/>

This innocent change (just swapping two lines) seems to have the impact that XModeler does not notice the duplicate introduction of the same attribute in the firstInSubClass.xml case, looking like this:

(The behavior was also reproducable in the XModeler - version 2.0.3 - GUI: when doing it in one order, the creation of a "double attribute" is accepted, when doing it in the other order, it isn't. )