SelectionModel needs the notion of "anchor".

Why do we need an anchor at all?

- its semantic is well-known and used across ux specs (f.i. https://wiki.openjdk.java.net/display/OpenJFX/ListView+User+Experience+Documentation)

What's the current status?

- ad-hoc, api-free implementation in some xxBehaviour classes

What are the consequences of current status?

- no api -> no contract -> untestable
- duplication in several behaviours which are inconsistent
- hard to maintain: there are several issues, some fixed, some not, which might be related to incorrect anchor handling
- the fixes get increasingly unmanageable: class methods at more or less arbitrary locations, storage in the general purpose properties map of the view, inverse coupling from model --> behaviour (to name just the more obvious)

Suggested solution

- find a proper home for the anchor property: my best bet is on (Multiple?)/SelectionModel itself. Then guarantee that all the heavy lifting is done by the model (vs. by using code)

Why would Multiple/SelectionModel be a proper home?

- the anchor needs to be kept in sync with selections
- the anchor needs to be update on remove/add items
- model is responsible for doing both with its other properties, adding anchor doesn't increase the burden significantly

Work to do:

- update SelectionModel spec to include anchor
- update implementations to comply to the spec
- update xxBehaviours to fully rely on the model

Suggested target version: 9 (assuming that api changes are allowed)