ST6RI-890 Multiple default multiplicities are added if there is a nested alias

[seidewitz]

Previously, when a usage requiring a default multiplicity has a nested alias declaration, then many multiplicity elements were physically added, rather than just one, resulting in a validation error. Indeed, there was actually an infinite recursion during the name resolution in the alias declaration, which was only terminated by the throwing of a org.eclipse.xtext.linking.lazy.LazyLinkingResource$CyclicLinkingException.

The recursion happened in the TypeUtil::addMultiplicityTo method, which checked for an existing nested multiplicity element using the condition

!ownedMemberships.stream().map(Membership::getMemberElement).anyMatch(Multiplicity.class::isInstance)

An alias declaration is parsed as an ownedMembership, so it was included in the stream that is checked in this condition. However, it is not an OwningMembership, which means its memberElement value is a reference, which is a proxy requiring name resolution. But this name resolution began in the namespace of the containing usage, which triggerd adding memberships again, causing the recursive call to addMultiplicityTo.

This PR fixes the infinite recursion by changing the condition in addMultiplicityTo to

NamespaceUtil.getOwnedMembersOf(type).noneMatch(Multiplicity.class::isInstance)

The getOwnedMembersOf method filters the ownedMemberships of a namespace to only include OwningMemberships and then gets the ownedMemberElements of those. This skips alias Memberships, resolving the problem.