KERML11 — Type::specializes() Operation shall be Model-Level Evaluable and Accessible from Expressions

KerML spec declares (chapters 8.3.3.1.1, 8.3.3.1.10) that KerML::Type has some operations, which would be useful for building expressions in the user models. We have use cases where this is useful/necessary for profile building to specify baseType expressions in UAF (see issue#2).
More narrowly, the Type::specializes() operation is needed badly.
Unfortunately currently these operations are not accessible/available. The reason they do not work is that they are not provided/exposed in the KerML libraries and subsequently not implemented implemented/exposed in the reference implementation. KerML.kerml, Core::Type metaclass only declares attributes and not operations.
Thus:
1) Provided spec libraries shall expose more operations (at least Core::Type::specializes()). As a consequence the expressions using those operations shall become parse-able. Operations shall be marked with model-level evaluability flag.
2) reference implementation should be able to evaluate such expressions.
3) A test case in the conformance WG should check this operation availability.
Example:
/**** Some domain library - e.g. UAF *****/

part def SpecialContainedType;
part def OrdinaryType;

part def SpecialContainerType;

metadata def DomainSpecificMetadata :> Metaobjects::SemanticMetadata {
:>> annotatedElement : SysML::PartUsage;

:>> baseType =
if ((annotatedElement.owner as KerML::Type).specializes(SpecialContainerType meta SysML::PartDefinition))
? SpecialContainedType meta SysML::PartDefinition
else OrdinaryType meta SysML::PartDefinition;
}

/**** User model ******/

part def UserContainerPartFromSpecDomain :> SpecialContainerType

#DomainSpecificMetadata part ordinaryUserPart1;

part def UnspecializedUserContainerPart

/*
The expectation is that specialUserPart specializes SpecialContainedType, while ordinaryUserPart1 and ordinaryUserPart2 specializes OrdinaryType.
This is because baseType expression stipulates that parts inside SpecialContainerType-typed containers must have slightly different specializations
The current behavior is that .specializes() invocation fails to compile.
*/