Feature: Add a public tuning and measurement tool holder #375

Description, motivation and use case
Tuning and measurement tools are currently stored in ElementHolder, with several default-specific properties directly on the base holder. The original holder proposal groups them under a dedicated tool namespace so that users can discover named tools and access defaults consistently.

This keeps the base holder focused on shared element access while providing a clear entry point for tuning workflows.

Proposed solution
Add a public tool property returning a tool holder:

• tool.get(name) returns the named tuning or measurement tool.
• tool.get() returns all configured tools as an untyped collection.
• Typed convenience properties resolve the corresponding default names: tune, trm, orbit, orm, chromaticity, crm, and dispersion.

Each typed property must validate its configured object type and raise a clear PyAMLException when its default is missing or incompatible. Keep the existing direct properties on ElementHolder for backward compatibility.

Describe alternatives you've considered
Leaving every default property on ElementHolder preserves existing code but makes the base API grow with each new tool. Returning raw entries from _TOOLS would not provide default-name mapping or type validation.

Example

tune_correction = sr.live.tool.tune
tune_correction.set([0.31, 0.22])

tune_response = sr.live.tool.trm
tune_response.measure()

other_tool = sr.live.tool.get("OTHER_TUNE_CORRECTION")
all_tools = sr.live.tool.get()

Additional context
Parent issue: ElementHolder API refurbishment #199.

ElementHolder already has internal tool lookup and direct properties for several default tools. This issue restructures those public entry points without removing the existing API.

Checklist

• I've assigned this issue to a project
• I've @-mentioned relevant people