EMF reading-compatibility follow-ups: @feature.N positional fragments, xmi:id resolution

[samatstariongroup]

Context

Follow-up to #99, which was scoped (see #105) to the high-value, low-risk items: the minor unread
features (EReference.eKeys, EClassifier.instanceTypeName, EEnumLiteral.literal,
EAnnotation.references) and unwrapping a single-package <xmi:XMI> document root. This issue tracks
the remaining EMF URI-fragment-resolution items that were deliberately deferred there.

Both are rare in hand-authored .ecore (EMF defaults to name-based URI fragments), which is why they
were split off rather than blocking #99.

The third deferred item, EAnnotation.contents (which needs a dynamic EObject), has been split
into its own issue: #109. It is independent of the two items below.

Remaining items

1. @feature.N positional URI-fragment resolution. Resource.GetEObject resolves name-based
fragments (#//Class/feature) but not the positional form some tools emit, e.g.
#//@eClassifiers.3/@eStructuralFeatures.1 (EMF: BasicEObjectImpl.eObjectForURIFragmentSegment).
Direction: navigate structurally — map the @feature segment to the owning object's containment list
(eClassifiers, eStructuralFeatures, eOperations, eLiterals, eSubpackages, …) and index into
it. (The name.N disambiguation form already resolves since #96, since the disambiguated identifier is
the cache key.)

2. Bare xmi:id fragment resolution. A URI fragment without a leading / is an intrinsic
xmi:id, resolved by EMF via getEObjectByID. .ecore files rarely carry xmi:id, but when they do
these references are currently unresolvable. Direction: capture any xmi:id attribute during ReadXml
into an id→object map on the resource and consult it in GetEObject when the fragment is not a
/-rooted path.

Notes

• Reference implementation: org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/resource/impl/ResourceImpl.java
  (getEObject, getEObjectByID), impl/BasicEObjectImpl.java (eObjectForURIFragmentSegment).
• Each item is independent and can be tackled separately.