Hierarchical device properties

[henrypinkard]

Originally proposed in #258 along with standard properties (which have now been independently implemented in #584). A summary of the remaining work that would be needed to implement a hierarchical property mechanism

Benefits

• Improved organization of properties, especially for devices with many properties
• More intuitive navigation of related properties
• Foundation for future property group operations
• Better user experience when working with complex devices

Core Functionality

• Introduce hierarchical property naming using // and / delimiters (e.g., //Group/SubGroup/Property)
• Allow creation of properties with hierarchical names through new API functions
• Enforce that existing CreateProperty() functions reject names containing //
• Ensure existing properties without hierarchical syntax continue to work as before

API Changes

• Add new functions to create hierarchical properties in device layer
• Maybe implement functions in the MMCore API to retrieve properties based on their group hierarchy

Backwards Compatibility

• Existing property names without hierarchical syntax remain valid
• Config files with non-hierarchical property names continue to load correctly
• Property browser displays hierarchical properties with their full path if UI enhancements are not yet implemented

GUI Enhancements (Future Work)

• Update property browser to display hierarchical properties in a collapsible tree structure
• Groups can be expanded/collapsed to show/hide their contained properties
• Property browser sorts properties by their hierarchical structure

Implementation Guidelines

• Hierarchical structure is purely a naming convention that exists at the API level
• Internally, full property paths are used for uniqueness and identification
• No changes needed to how properties are stored in the system state cache
• Config files will store the full hierarchical property names