feat: allow application MMS process-control runtimes

[masarray]

What changed

• add MmsCompositeAssociationRuntime so multiple per-association MMS runtimes can coexist
• add optional AssociationRuntimeFactory to IedSimulatorMmsServerOptions
• preserve the built-in RCB/reporting runtime and compose it with an application-supplied runtime
• keep the default simulator data model read-only when no application runtime claims a target
• dispose application runtimes with their MMS association
• add regression coverage for runtime write fall-through, first-owner reads, and disposal

Why

ARVREL's AVR virtual IED needs IEC 61850 process controls and writable AVR setting points while reusing the existing ARIEC61850 TPKT/COTP/ACSE/MMS server, BER dispatcher and reporting runtime. This extension lets an application claim only explicitly modeled process targets. Every unrelated write still reaches the existing read-only guard.

ARVREL consumer

ARVREL PR #89 pins commit 0e1e2de693bc3f5427f6b1f23fcc6c3e6fe1f60e from this branch and supplies a per-association AVR runtime for:

• SBO / SBOw / Oper / Cancel process controls
• ATCC1.Auto
• ATCC1.LTCBlk
• YLTC1.TapChg
• selected AVR setting writes

The application runtime queues accepted commands back to ARVREL's WPF/AVR authority thread; the MMS socket worker does not mutate the regulator engine directly.

Safety / compatibility

• no default write behavior changes
• RCB attribute handling remains owned by the existing reporting runtime
• applications opt in explicitly per association
• network transport, ACSE association and MMS BER dispatch semantics remain centralized in ARIEC61850
• if no application runtime claims a write target, the normal read-only rejection remains authoritative

Validation

• .NET CI #255 passes build and test for commit 0e1e2de693bc3f5427f6b1f23fcc6c3e6fe1f60e
• ARVREL .NET CI #533 also builds/tests successfully while consuming this exact commit
• PR remains draft until live SAS control validation is completed