Structural weaver merges class and implementation class by name for extends

[Matthias Schoettle]

The following can be reproduced using Association based on commit 3720a76.

1. Create an aspect
2. Create class A and B
3. Create association A ---> B (with 1..* multiplicity)
4. Select HashMap and then select a Key (e.g., String)
5. Weave

The result will contain HashMapand Collection<B>. However, this collection (java.util.Collection) contains methods that are from KeyIndexed.Collection.

I.e., KeyIndexed contains the implementation class java.util.Collection and maps Association.Collection to KeyIndexed.Collection.

Because of the equal names it seems that Collection is also merged into java.util.Collection. In fact, the PreProcessor in processExtends() only checks the name. Instead, it should check the instanceClassName for implementation classes and also never do it (based on name equality) from Class to ImplementationClass.

[Matthias Schoettle]

Also, in PostProcessor, duplicates are detected and merged. Here, if the two classes that are compared are not ImplementationClasses, a simple name check is performed. This leads to the case that Object (implementation class) and Object (class) are considered the same.

[Matthias Schoettle]

Resolves #365: Changes Pre and Post processor to use utility method for classfier comparison.

Instead of defining/implementing the equality check for classifiers in the weaver, the already existent utility method from RAMModelUtil is used. This method already takes care of properly distinguishing between ImplementationClass and Class.

→ <<cset f24579a92d01>>

[Matthias Schoettle]

Models: Updates Association models to reflect changes to weaver.

The Object class is now concern partial, but needs to be redeclared in each lower-level model which doesn't map it to somethin concrete.

References #365.

→ <<cset 61ce12f45660>>