Revert "Merge branch 'st' of git://github.com/suitabletech/qtdeclarative into st"

This reverts commit 29f6d4ea1eed176d4221e6e89330c9cf5aefdf66, reversing
changes made to f370632d783118b1a46e961079b5af0eccaeb92a.
[Regression] Fix lazy binding evaluation

Commit 04774bb14c81688f86a2b31b8624bde8ebf59062 long time ago introduced the
concept of fixed order binding initialization with lazy evaluation, where a bit
is reserved for each binding that indicates whether it's been initialized the
first time or not. When reading a property on a QObject, we'd check if the
corresponding binding for the property has been initialized or not and flush
(i.e. execute) the binding if necessary.

As part of the V4/V8 clean-up, commit 1eb41200948ab414f1c47d93123b41c547a993df
removed the StoreV8Binding instruction, which made the call for setting the
this-binding-is-not-evaluated-yet bit. Nowadays we only use StoreBinding, for
which this optimization was never implemented (and not needed really). Now that
we have a unified JS code path, we need to set the pending binding bit and also
make sure that we call flushPendingBinding for any JS side property access
(accelerated or not).

Also flushPendingBindingImpl had two bugs:

   * In an attempt of trying to find the binding to flush, it could happen that
     we'd try to flush a previously destroyed binding (m_mePtr is null), so
     the b variable would remain the first binding in the object and we'd flush
     the wrong one (instead of none). Added a missing check to verify that the
     property index matches.
   * Also resetting the mePtr must be done through clear(), to ensure that the
     pointer in bindValues in the VME is also cleared, to avoid re-enabling the
     same binding again in complete();

Task-number: QTBUG-36441

Change-Id: Icdb0c8fb036051fd5d6c4d33b10cd0c0ed9a9d5c
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Fix spurious binding loop errors in QtQuick Controls and other places

Commit 5dc7649f5ad7dca6e13707e827d001c3f118a6ef caused this regression,
as a result of lazy binding evaluation and self-referencing objects:

    import QtQml 2.0
    QtObject {
        property QtObject objectRef : subObject
        property QtObject blah: QtObject {
            id: subObject
            property int value: 42
            property int blah: objectRef.value
        }
    }

When blah is evaluated, we now lazily initialize objectRef - as opposed to
previously throwing an exception and then when objectRef gets initialized we
re-evaluate blah due to its dependency. So while evaluating "objectRef.value"
for blah, we initialize objectRef by evaluating "subObject", and after doing
that we write the "objectRef" property. That triggers a change notification,
and since the objectRef reference for blah is a compile-time known dependency,
the change notification triggers a re-evaluation of "blah", which is the
binding loop.

What's wrong here is that we register the pre-defined captures before the
code execution, when we should register them after the evaluation, or strictly
speaking after flushing pending bindings, like it is the case for individual
properties in bindings where we could not pre-determine the depenencies.

Change-Id: I9fb0c7583cba9d9b71c9ada2791fe87574f6ef44
Reviewed-by: Lars Knoll <lars.knoll@digia.com>