UMLR — Migrate UML::Component's ability to own UML::PackageableElements to UML::Class

UML2.4.1 Superstructure, section 8.3, Figure 8.4 shows that UML::Component has a composite association to UML::PackageElement; that is:

UML::Component::packagedElement : UML::PackageableElement

This is the only place in the UML metamodel where a kind of UML::Classifier has the capability to own arbitrary kinds of UML::PackageableElements.

As long as the classifier capabilities needed in practice are within the scope of what UML::Class already provides, then it is practically very useful to use UML::Component in lieu of UML::Class.
By doing so, a UML::Component-as-an-enhanced-UML::Class gains the capability to own additional kinds of UML::PackageElements that a plain UML::Class cannot; e.g.:

UML::Package, UML::Dependency, UML::InformationFlow, UML::ValueSpecification, UML::InstanceSpecification, UML::Event, UML::Observation, UML::Profile, UML::Model.

Unfortunately, other kinds of UML::Class do not get such benefits. For example, a UML::StateMachine is a kind of UML::Class just like UML::Component but unlike UML::Component, it can't own arbitrary UML::PackageableElements.
In particular, it cannot own any UML::Event even though this would make eminent sense in some cases (e.g., internal events not visible outside of the UML::StateMachine).

Finally, the well-formedness and semantics of a kind of UML::Class with namespace-nested UML::PackageableElements need to be addressed for unusual combinations including but not necessarily limited to the following cases:

1) nested UML::Profiles and UML::ProfileApplications
2) specialization of a general classifier nested within its packagedElements
3) applying a stereotype defined in a UML::Profile nested within its packagedElements
4) the target of an elementImport from a UML::Namespace nested within its packagedElements