Specific feature selection type for context commands

[GeKtvi]

This PR is a follow-up to the context menu items/icons PR and should be merged after it.

• It extends the context-menu API to support specific feature selection (adds SpecificFeatureSelectionType and wires it into the context item/icon registration flow).
• For specific feature types, CommandContextItemCreated uses SolidWorks AddMenuPopupItem4 instead of AddMenuPopupItem3 (feature type names from IFeature.GetTypeName2 instead of general selection type enums).
• It touches the same CommandContext* and selection infrastructure as the base PR

Notes

• This PR modifies existing context menu types and selection infrastructure and adds:
  • SolidDna/CADBooster.SolidDna/SolidWorks/SelectionManager/SpecificFeatureSelectionType.cs

Why SpecificFeatureSelectionType is separate from SelectionType

SpecificFeatureSelectionType is just a helper catalog class to create/access SelectionType instances for specific SolidWorks feature type names (for UI context menu filtering).

SelectionType represents the generic SolidWorks selection context (swSelectType_e + related string values) and is used broadly across the library. “Specific feature types” are a different dimension: they are identified by the feature type name strings returned by IFeature.GetTypeName/GetTypeName2 (large, version-dependent list). SpecificFeatureSelectionType is intentionally focused on UI context menu selection/registration (filtering context menu items by feature type name). Keeping it separate avoids bloating SelectionType, avoids implying it’s supported everywhere, and keeps the API clearer: generic selection context vs feature-type-name based UI filtering.

Why this is separate from ModelFeatureType / ModelFeatureTypeMapping

ModelFeatureType / ModelFeatureTypeMapping exist to classify a ModelFeature into a higher-level enum (often mapping many raw GetTypeName2 strings to a single enum value, and sometimes branching by SolidWorks version). Context menu registration for “specific feature selection” needs the raw feature type name string (the UI/API filter value), not a computed/normalized enum classification. The mapping is not a stable source for that filter value because it is many-to-one (you can’t reliably reverse-map enum → one raw type name), it can be version-dependent (VersionYear branches), and it operates on a ModelFeature instance (FeatureTypeName) rather than providing a canonical list of raw feature type strings for UI filtering.

Suggested library improvements (related to this PR)

ModelFeature.GetFeatureTypeName()

Handle the Instant3D "ICE" case by falling back to IFeature.GetTypeName() when GetTypeName2() returns the generic "ICE".

protected string GetFeatureTypeName()
{
    var type2 = BaseObject.GetTypeName2();

    // For Instant3D feature (i.e., "ICE") SolidWorks returns generic "ICE" value
    // If it returned we handle it and call GetTypeName()
    // Docs:
    // https://help.solidworks.com/2026/english/api/sldworksapi/solidworks.interop.sldworks~solidworks.interop.sldworks.ifeature~gettypename.html
    // https://help.solidworks.com/2026/english/api/sldworksapi/SOLIDWORKS.Interop.sldworks~SOLIDWORKS.Interop.sldworks.IFeature~GetTypeName2.html
    return type2 == "ICE" ? BaseObject.GetTypeName() : type2;
}

SelectedObject.IsFeature

Simplify feature detection by checking whether the selected BaseObject is an Feature. Current implementation not covers all cases.

public bool IsFeature => BaseObject as Feature is not null;