2.0: make CanOpenDeviceDescription immutable — edit, then bind again #299

Successor of #296, for the next major.

#296 is closed by documenting the rule as it stands (option c): a bound CanOpenDeviceDescription is read without synchronization by the peer-SDO gate on every client SDO call, by the loader, by the foreign PDO and SRDO observers and by a safety transaction's one-time reading, so it is edited in place only while no call that reads it is running, and an edit during one is unsupported with an unspecified outcome: the EdsDcfNet dictionaries are not safe for a read concurrent with a write, so an enumerating reader may fail with InvalidOperationException (reported as that call's failure), and a reader with single lookups around its own awaits — the observers' file fallback, the gate's Contains — may answer from a part-old, part-new description or report no match, with no error.

The lasting fix is option (a): an immutable description. CanOpenDeviceDescription copies the EdsDcfNet model at construction and exposes read-only views; changing a description means edit, then bind again. Then the gate, the loader, the observers and the safety transaction read a value that cannot change under them, DescribedObjects.Capture becomes the constructor's job, the step-D expectation question (#291, FR-CO-045) disappears, and Step_D_Uses_The_Bound_Description_As_It_Is_Now changes meaning: a rebind is seen, an in-place edit is not possible.

Why not now: Objects hands out the mutable EdsDcfNet.Models.ObjectDictionary, and the README documents editing a bound instance in place. Making it read-only is feat! with a BREAKING CHANGE: footer, a major release, and belongs in the 2.0 set, not in a fix.

Option (b), a lock the library owns with an Edit(Action<…>) method, was rejected: it covers only the readers, while a writer reaching description.Objects.Objects[...] bypasses it, so it is either advisory or (a) by another route.