Add app-driven limit alarm state APIs

[kevinherron]

Limit alarms work well when Milo evaluates a single numeric value, but the API is awkward for applications that have already calculated the alarm state themselves. Exclusive callers must redundantly provide both Active and a limit state, while non-exclusive callers cannot atomically provide the complete active set and choose which state controls the message, display name, and severity. Writing the individual nodes directly bypasses Milo's Condition transition rules.

This PR adds direct state APIs for both alarm types. Applications can provide an exclusive state, or a complete non-exclusive state set with an explicitly selected effective state. Milo still owns validation, locking, acknowledgements, timestamps, shelving, Retain, snapshots, and event generation, so each application-driven update remains one coherent Condition transition.

What changed

• Add ExclusiveLimitAlarm.setLimitState(...), where null deactivates the alarm.
• Add NonExclusiveLimitAlarm.setLimitStates(...) and getEffectiveLimitState().
• Validate and defensively copy non-exclusive state tuples before touching Condition state.
• Use the caller-selected effective state for Message, EffectiveDisplayName, and Severity.
• Preserve the effective state across snapshot capture and restore.
• Maintain ActiveState.EffectiveTransitionTime for modeled limit-state changes.
• Preserve custom subtype and optional-node behavior through attach and adopt.
• Add focused coverage for state transitions, acknowledgements, timestamps, shelving, snapshots, and custom subtypes.

Existing evaluate(double) behavior remains unchanged for applications that want Milo's standard scalar limit evaluation.