cxx-qt-gen: use impl cxx_qt::QObject<T> block for invokables

[ahayzen-kdab]

This helps later as the invokables are implemented onto a different
struct, so this clearly defines the split between C++ and Rust
methods etc.

[ahayzen-kdab]

@LeonMatthesKDAB did we decide if we were going to call this impl Qt<T> or impl cxx_qt<T> ? As i think the Qt felt more natural for saying these are "Qt" invokables, but the cxx_qt was better to avoid clashes ? Maybe even cxx_qt::invokables could be considered as that then matches cxx_qt::signals etc ?

[ahayzen-kdab]

@LeonMatthesKDAB did we decide if we were going to call this impl Qt<T> or impl cxx_qt<T> ? As i think the Qt felt more natural for saying these are "Qt" invokables, but the cxx_qt was better to avoid clashes ? Maybe even cxx_qt::invokables could be considered as that then matches cxx_qt::signals etc ?

So i'm wondering if this is the route (assuming valid syntax)

impl cxx_qt::invokables<MyObject> {
  #[invokable]
  pub fn my_invokable(self: Pin<&mut Self>) {

  }
}

impl MyObject {
  pub fn rust_only_method(&self) {

  }
}

@LeonMatthesKDAB where did our discussion end up on having like #[invokable(return-as-value)] and #[property(as-value)] stuff for UniquePtr end up? I can't see it now as there were options like #[invokable(return QColor)] as well...

[LeonMatthesKDAB]

So i'm wondering if this is the route (assuming valid syntax)

impl cxx_qt::invokables<MyObject> {
  #[invokable]
  pub fn my_invokable(self: Pin<&mut Self>) {

  }
}

impl MyObject {
  pub fn rust_only_method(&self) {

  }
}

We shouldn't use impl invokables<MyObject>, as it still makes sense to have non-invokable (aka not to C++ exposed) methods defined within the impl Qt<MyObject> (or whatever we end up calling it).
Whilst you can define Rust-only methods directly on MyObject, you might want to have a private method that is still capable of emitting a Signal for example. That you would implement on Qt<MyObject> but without #[invokable].

But regarding the cxx_qt:: prefix. That does make sense for consistencies sake.
So something like: impl cxx_qt::QObject<MyObject> or impl cxx_qt::Qt<MyObject>. My local playground project even uses impl cxx_qt<MyObject>, but maybe impl cxx_qt::Qt<MyObject> is a bit more consistent with the other macros we have.
Later we could add the ability to add a use cxx_qt::Qt or use cxx_qt::prelude::*, to reduce the boilerplate.

@LeonMatthesKDAB where did our discussion end up on having like #[invokable(return-as-value)] and #[property(as-value)] stuff for UniquePtr end up? I can't see it now as there were options like #[invokable(return QColor)] as well...

I'm unsure whether we reached a consensus on that or whether we were still just discussing options 🤔
Do you need a decision on this for this PR already?

[LeonMatthesKDAB]

Going in the right direction. A bit of clarification regarding the purposes of impl Qt<...> vs impl ... are still necessary :)

[LeonMatthesKDAB]

Just one typo, then we're good to go :)

[LeonMatthesKDAB]

LGTM