Feature: Add generic ElementHolder collection access #366

Description, motivation and use case
ElementHolder stores every element for a control mode, but its public API still requires callers to know whether an object is an individual element or a configured array. The typed holders cover magnets and BPMs, but users cannot yet browse all elements through one consistent collection interface.

This matters for interactive workflows that start from a mode and need to select elements by name before applying existing array operations.

Proposed solution
Add a generic public collection API to ElementHolder:

• holder.get() returns all attached elements as an ElementArray.
• holder[:] is equivalent to holder.get().
• holder[pattern] selects elements by name wildcard and returns the most specific compatible array type.

Keep get_element() and get_elements() unchanged for backward compatibility. Exact configured-array lookup remains available through get_elements(name); the new API is for generic collection navigation.

Describe alternatives you've considered
Keeping only get_element() and get_elements() preserves the current API, but requires callers to decide in advance whether they need a singleton or an array. Exposing the internal _ALL mapping would avoid new methods but would leak implementation details and bypass typed array behavior.

Example

all_elements = sr.live.get()
same_elements = sr.live[:]

bpms = sr.live["BPM*"]

cell_elements = sr.live.get_elements("CELL08")
cell_magnets = sr.live.magnets[:] & cell_elements

Additional context
Parent issue: ElementHolder API refurbishment #199.

ElementArray already provides slicing, wildcard selection, and set-like operations. Domain-specific field filtering remains the responsibility of typed arrays; for example, model_name is a magnet-specific field.

Checklist

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