Allow directly setting child objects in Rust

[LorenDB]

In many cases, a non-trivial QML app will require creating a QObject that has another QObject exposed as a property. For example, in a calculator app, you might choose to implement the QML-to-C++/Rust bridge by creating a singleton Calculator object; however, you probably will want your Calculator singleton to have a property history that stores a QAbstractListModel with the history. Unfortunately, it doesn't seem to be possible to directly set the history property from Rust. Instead, you have to create a C++ factory function that returns a new HistoryModel, which then can be used on the Rust side.

It might be a good idea to create a factory function to allow allocating QObjects for situations like this. This could possibly be made opt-in via a macro or trait.

[ahayzen-kdab]

Wonder if this could be linked to the QtObject and QObject trait ideas in #562 if we did it via that route.

We need to consider what happens if you have a constructor with arguments though 🤔 Or would it only work for the empty arguments constructor ...

[LeonMatthesKDAB]

Hm, in theory we do actually have the information needed for this through the Constructor trait.
So maybe we can figure something out there 🤔
we'd want to possibly provide some options on how to construct your QObject though... Should it return a UniquePtr? Or a SharedPtr? Unfortunately it seems you can't construct a SharedPtr from a raw pointer.
Anyhow, seems like a good thing to figure out for 0.7 🤔

[LeonMatthesKDAB]

This is sort of related to #823 , as those functions would allow you to instantiate any QObject.