`ReferenceObject::init` currently allocates connections to certain signals to enable a reduction of the amount of reads the `ReferenceObject` needs to perform, by using the signal to identify when the data that is being represented was invalidated. In particular, when the `ReferenceObject` is part of a chain that traces back to a `Q_PROPERTY`, and that property either has a `NOTIFY` signal or is a `BINDABLE`, a connection to the signal or a subscription to the `BINDABLE` is activated. When one of those is done, we further construct a connection to the `destroyed` signal of the object that holds the property, to ensure that a read is performed and our data is invalidated if that object is destroyed. The code that performs this process, in `ReferenceObject::init`, was written with the incorrect assumption that a property either has a `NOTIFY` signal or is `BINDABLE`, but not both. In truth, a property might both have a `NOTIFY` signal and be a `BINDABLE`. When this is the case, the current code would allocate a connection to the `destroyed` signal on the same memory block twice, once when setting up a connection to the `NOTIFY` signal and once when subscribing to the `BINDABLE`, without ensuring that the previously allocated connection was disposed of. To avoid this issue, the code that takes care of setting up the connections is now exclusive between the two connections path, with a priority on the `BINDABLE` subscription, as this mirrors the already existing preference we have when dealing with bindings and is expected to be slightly more performant. The documentation for this connection process was modified to add a small mention of this priority of execution. Some defensive asserts were added to the relevant connection code, to ensure that we can catch the construction of multiple connections at once, which is to be considered a bug. The code that takes care of disposing of the `destroyed` signal connection was modified to ensure that we only take into account our allocation strategy and not our actual connection status, which, while they shouldn't generally be in discord, might incorrectly avoid a necessary disposal if they would. A comment that related to the condition for the disposal was modified to be more precise with regards to the new condition. Some test cases were added to `tst_qqmllanguage` to check the leak and `BINDABLE` preference behavior. Change-Id: Ibdc657fd857a8838797e47ff235f67cfaeec20de Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>