Rework QObject deletion mechanism

Instead of the qv4mm knowing about different ways of deleting the QObjects
of the QObject JS wrappers (and their timing!), provide an interface between
the two.

Before destroying a managed object, we allow for the object to register a
Deletable instance in a singly linked list of deletable objects that will be
deleted right after the sweep, but before the gc returns to application.

This allows for a behavior that is identical with V8: When GC runs, the
QML Component.onDestruction callbacks are called _after_ the sweep but
before returning to the application. The QObject however is deleted later,
unless this is the very last run of the GC (as indicated by the lastCall
property).

Change-Id: I1a2f127f4634c7ecc8c89b45e8b0a575c0ef772e
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Fix qqmlecmascript::propertyVarOwnership

Don't rely on o = new Date in the test-case to really clear the last "reference"
on the stack. As it turns out, in v4, we sometimes allocate the result of "new Date"
in a different slot and the old slot is still around (and thus the object is
visible and marked).

Instead work with separate scopes, which requires a little helper function in JS.

Change-Id: I5f318feaccfc7d83dbe28be043a0ee83e0c16355
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Fix ownership of JS value returned by QJSEngine::newQObject

As documented, the ownership should be JavaScriptOwned, which means:
Keep the QObject alive if there's a parent or some other JS object is
referencing it.

Fixes three QJSEngine auto-tests

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