manual sweep of !53883: split ISelectionAccessor into ISelectionReadAccessor and ISelectionWriteAccessor

The current users of ISelectionAccessor interface only ever use it to read or to write a selection decoration, never both, and none of the implementations actually benefit from doing both in the same class. Quite the contrary, a lot of the implementations can only do reading and only provide an error when trying to write to them. Splitting the interface into two (and the implementations as needed) makes the code more clear, and avoids having all the functions in the implementations that just produce an error because that part of the interface can not be implemented in the class.

Implementation-wise I split ISelectionAccessor into ISelectionReadAccessor and ISelectionWriteAccessor, and propagated that through the code, using the read or write interface as necessary. Implementations of the interface were changed to implement either only the read-interface or split into implementations of both interfaces.

The only code that is actually shared between both accessor types is the label() member for debugging (which is duplicated), and the code that parses the "selection,as_bits" syntax (which I handled via a SplitData helper class).