This is needed, since we will need similar mapping functions for
mapping other things as well, like direction (normal) and rotation.

Anyone can call calculateGlobalVariables() at any time. So by the
time the global transform pass calls out to the node, the
calulation might already have been done. So for those cases, ensure
that we always store if the global transform has changed whenever
we calculate global variables.

This is more in line with the current naming found in QQuickItem, where
mapTo/From is used. 'scene' is also more well defined in QtQuick3D
than 'world'.

Whenever someone creates a connection to any of the global transform releated
properties for a QQuick3DNode, we inform the scene manager about it. What it
means is that we need to calulate the global transform and emit changes to it
whenever it changes. But knowing when it changes is costly, since it will change
whenever the transform of an ancestor change (and we don't want to listen for
that all the way to the root). So the scene manager will instead delay all global
transform calculations to a be done in a single pass before we update instead.

In many cases there is no time to wait for the scene graph to update before updating
the global matrix for a node. If you e.g change the position of a node, you
need to be able to e.g query to globalPosition right after in order to
position other objects in the scene relative to it. Waiting for the scenegraph
to update will cause such calculations to end up using old values.

Many of the functions found in QQuick3DNode belongs better in
QSSGEulerAngleConverter. By refactoring them inside that class, we
can also use them from other places, and in particular from
QQuick3DNode where we need to calculate the global matrix.

This calculateLocalTransform() creates a right-handed transform.
This means that if the nodes orientation is already right-handed, we
don't need to do any flipping. This is only needed when the
node is left-handed (since we create a right-handed transform). And
then we do it in one go at the end of the function.

If we flip the z value for position/pivot when the orientation is
right-handed, we effectively see the position as left-handed. E.g
if the user sets the z position to be -100 for a right-handed
node, we would flip it to be at position 100 instead. This would
be against the reason the set a right-handed system on a node
in the first place.