FrameGraphItems C++ Qml API

FrameGraphItems are different from usual Qt3D elements as they inherit from
FrameGraphItem which is a sublcass of Node. As Qml items should now inherit
Quick3DNode instead of Node, this makes using old FrameGraphItems as they were
impossible because children cannot be added to a Node in Qml if the Node is
not a Quick3DNode.

One method that reduces code duplication to the minimum is creating abstract
classes for Viewport, RenderTargetSelector, CameraSelector, RenderPassFilter
and TechniqueFilter. Then the C++ FrameGraphItem Nodes can inherit from node
and one of those abstracts. On the QML side, Quick3D FrameGraphItems inherit
from Quick3DNode and one of the base class.

Because multiple inheritance of QObject is not possible, abstract
FrameGraphItems are not subclasses of QObject and are therefore declared as
Q_INTERFACES so as to be able to perform qobject_cast.

Change-Id: Ibf1350a53ce409ff03aad8d0fd8f5b7d6cc26fc0
Reviewed-by: Sean Harmer <sean.harmer@kdab.com>
Abstract Entity, EntityNode and Quick3DEntity

Because Node no longer holds QQmlListProperties, Entity which inherited Node
could'nt be used to have nested children in Qml because there was no longer a
data DefaultProperty.

To solve that issue Entity has become an abstract class encapsulating most
what an Entity used to contain. EntityNode is a class bound to be used by
the C++ API and it subclasses Node and Entity. Regarding the Qml API,
Quick3DEntity subclasses Quick3DNode and Entity.

RenderSceneBuilder and NodeVisitor have been slightly modified to work with
those changes but the backend is pretty much the same. The big change is that
Entity is no longer a QObject and no logner inherits Node. That means Node and
Entity have to be used along side on the backend. On the frontend or other
Aspects subclassing EntityNode or Quick3DEntity should be pretty much the same
as subclassing Entity prior this change.

Component classes have not been touched so they cannot contain nested QtQuick2
elements in QML. As Entity and Nodes can hold QtQuick2 Components this isn't a
big issue. Also as the DefaultProperty of each Component subclasses may
differ, keeping them as they are at the moment could make sense.

Note: This patch restored rendering. The code is a bit messy at the
moment but necessary to keep commits small. Follow up patches will clean
things up a bit and move the Qml and C++ API in distinct subprojects.

Change-Id: Ia048812f51bbbd43ec2ee754b5120b7ec3174436
Reviewed-by: Sean Harmer <sean.harmer@kdab.com>