Fix method overload calling of Qt slots from JavaScript

After commit ac57f185d1a2203cd4b585df7bd7af01c3ec33ed we succeed in selecting
the correct overload based on the supplied arguments. However when calling
slots on objects without a property cache, we end up using the local "dummy"
variable to store the synthetic propert data. We also store the currently best
patch in the "best" variable, which is a _pointer_ to the property data of the
match. Suppose we have 5 overloads to choose from, we find that the 3rd is
the best. Then we try the fourth but find it unsufficient and break out of
the loop. Unfortunately the "dummy" property data at this point contains the
data of the fourth (wrong) overload, and our best match variable points to it.
So then when we finally call the method, we do it based on the wrong property
data.

The easy patch is to simply copy the few bytes of property data, so "best" is
stored by value instead of pointer.

Change-Id: Ie2ebbdb88a117770b6c7b9490e1c634077020e9d
Reviewed-by: Karsten Heimrich <karsten.heimrich@digia.com>
Fix bindings to when property of States not always working

The "when" property is of type QQmlBinding* and we special case that type when
writing property bindings. However in order for that to work, the meta-type for
QQmlBinding* needs to be registered at the point in time when resolving
properties in the type compiler. In Qt 5.1/5.2 this worked by accident due to
a different code paths that implicitly registered the meta-type earlier from a
different location.

There are a couple of property types for which we have special handling, such as
QQmlV4Handler and QJSvalue, besides QQmlBinding*. We do register them explicitly
at engine initialization time, and therefore we should also initialize the meta-type
for QQmlBinding* there.

Task-number: QTBUG-39421
Change-Id: Iec8609848b632afa52aa42cf0b807330c74f6f3a
Reviewed-by: Joona Petrell <joona.petrell@jollamobile.com>
Use the correct precision specifier in visualizer GLSL.

Task-number: QTBUG-39119
Change-Id: I0ec4909167f5694ce4229df8202c89742be21d0a
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
Reviewed-by: Andrew Knight <andrew.knight@digia.com>