bi-directional or multi-sync variation of Binding

A conventional "colon" binding (as in

Foo { value: sourceObject.prop }

) is single-directional. It can be supplemented with a Binding object to provide a reverse-direction binding (as in

Binding { target: sourceObject; property: "prop"; value: foo.value}

). But that's a little messy syntactically.

One case where this comes up is for checkboxes with incomplete exclusion rules, where checking one checkbox invalidates some others, but not all of them, so you can't just use mutually-exclusive radio buttons. See for example examples/quick/dialogs/FileDialogs.qml: the rules are defined in the C++ model, there are colon bindings to set the model properties based on the user's choices, and there are also Binding objects to override the checkboxes when the C++ model enforces its rules; but the colon bindings and Binding objects are confusing and cannot be side-by-side in the code.

So, one idea is to add a source property to Binding, and maybe also a bool "bidirectional" property, so that you could do something like this:

CheckBox {
   Binding on checked { 
       source: model
       property: "myBoolProp"
       bidirectional: true
   }
}

To make it even more generic, we could alternatively have a Sync element which is like an n-way version of Binding: it keeps the same property in sync across as many objects as you like. You would have to provide a list of IDs somehow, because the items probably couldn't be children. And actually, mutual exclusion could work in a similar way: it's like a sync with a different operator, XOR instead of AND.

Of course I realize that either of these would make binding loops more likely, so it needs a bit more thought whether we need any better mechanisms to detect and avoid binding loops than what we already have. In the case of a bidirectional binding, maybe we could have bool properties sourceConnected and targetConnected, to check whether either link has been broken because of a binding loop. And if the link is broken, is it temporary or not? should there be a way to try to reinstate it? (by e.g. setting sourceConnected back to true and then checking whether it stays true?)