profiles

Many companies restrict and enhance the CIM classes that can be used in an application, using what are called profiles. For example ENTSO-E uses the [Common Grid Model Exchange Specification (CGMES)](https://docstore.entsoe.eu/Documents/CIM_documents/IOP/CGMES_2_5_TechnicalSpecification_61970-600_Part%201_Ed2.pdf) which is a super/sub set of the CIM model.

This issue tracks the work necessary to support profiles.

Of interest:
- provide a workflow for additional .eap model files to generate class files adhering to end-user profiles (see Issue #8) with user-defined namespaces and super/sub sets of the full CIM model that can be used at runtime as a "CIM version" - i.e. a dynamically loaded CIM version
- provide a (text based?) configuration mechanism that simply limits the available classes from a full CIM set that are read by the CIMReader - all others being discarded - i.e. a dynamically loaded CIM subset
- check if an 'electrical' configuration (of a CIM subset as above) which doesn't include Assets, Measurements, Locations, StateVariables, UsagePoint etc. allows the import of large CIM files on modest hardware
- provide a generic mechanism, in the absence of a compiled set of classes from a profile, to read, store and export custom properties (in other namespaces) via a key-value map of "unknown/unparsed" attributes attached to existing classes

Start with Issue #8 and the CIMReader entry point, then map how additional .eap model files and generated classes are currently handled. Clarify which profile capability is in scope first; done should include a defined workflow or configuration behavior, runtime profile handling, and coverage for the selected CIM files.

Written by the indexing model from the issue text.