Unify terminology somewhat.

namespace (from Debugger::Internal) as they are exported classes.
Introduce private classes to avoid exposing private JS debugger
headers.

Reviewed by: Lasse Holmstedt

This should speed up the matching between the AST nodes and the debugIds

There is now a hook in QDeclarative itself for that.
Needs commit af2b28f9ca07057 of Qt

Now, QmlEngine creates the connection to the inferior (debuggee), and
notifies QmlInspector when a connection is established. Before,
inspector created the debugger engin, which was wrong.

QmlEngine's responsibilities are connecting to the debuggee and basic
QML/JS debugging features like locals & watchers, breakpoints etc.
QmlInspector takes care of Live Preview and other fancy inspection
features.

Reviewed-by: hjk

Previously, the user had to navigate to the context of a qml item in
order to edit its source code in Live Preview mode. This change tells
the client to update when new objects are created on server-side, and
makes the editing possible without having to manually trigger updates.

This one should be called when a component is changed and components
using it need to be reloaded.

The crumble path shows the current context of the debugger/inspector.

To show the object string id's, the debug protocol is used to get them.
The problem is that the required methods in QDeclarativeContext(Data)
are not exposed, and it's too late to do it for 4.7.0. Hence this change
should be reverted in 4.8 when more efficient way of getting the id's
comes available.

Even if we should really care about all of them, the object that is the root
of all the graphical QML item is the usually last.

Also used 'int' instead of QDeclarativeDebugObjectReference for
the debug id in order not to use the private API from QMLJS

When the document is reloaded by the server, we need to refresh
refresh what was the loaded document, and refresh the debugIds

... with a little bit of refactoring.

But for some reason it does not seem to have an effect