Built-in Ecore type lookup uses substring matching; misnamed EBool key and ambiguous-match exceptions

[samatstariongroup]

Context

Found while validating ECoreNetto 7.0.9 against the Eclipse Capella 7.0 metamodel for STARIONGROUP/capella4net#2.

Problem

Resource.GetEObject matches built-in Ecore types by substring:

var ecoreType = this.eCoreTypes.SingleOrDefault(x => uriFragment.Contains(x.Key));

Two defects follow:

1. Wrong-key hits. The dictionary key for the boolean datatype is http://www.eclipse.org/emf/2002/Ecore#//EBool — not an Ecore type name. Capella references Ecore#//EBoolean, which only resolves because ...#//EBool is a substring of ...#//EBoolean. An exact-match lookup would have exposed the misnamed key immediately.
2. Ambiguous matches throw. Key pairs where one is a prefix of the other (//EEnum///EEnumLiteral, //EClass///EClassifier, //EString///EStringToStringMapEntry, EBool/EBooleanObject, ...) make SingleOrDefault throw InvalidOperationException: Sequence contains more than one matching element for fragments that contain the longer key.

Suggested direction

Normalize the fragment (strip the http://www.eclipse.org/emf/2002/Ecore# prefix if present) and do an exact dictionary lookup on the remaining //EName part; fix the EBool key to EBoolean.