Proposal for Q_OBJECT/Q_GADGET like mechanism for interfaces for QObject-based classes

Currently we have Q_OBJECT for QObject based object-types and Q_GADGET for value-types. There is also to some degree support for interfaces by Q_DECLARE_INTERFACE. However interfaces while useful in many situations has always been second class. There is no way to declare invokable methods or properties not to speak about signals or slots. But those would be extremely helpfull in a QObject and signal/slot dominated world.

E.g. when having a class that automatically saves changes in the configuration of objects, it could have the following member:

void ConfigManager::addConfigurable(IConfigurable *obj)
{
    m_configs.append(obj);
    connect(obj, &IConfigurable::configChanged, this, &ConfigManager::updateConfig);
}

My proposal would be to add a macro like Q_OBJECT_INTERFACE that declares the staticMetaObject method and pure virtual metaObject etc. A class containing this macro would therfore be only useful when derived from with multiple inheritance in a QObject-derived class. I don't have a complete concept of how it has to be integrated into the MOC and the other methods like qobject_interface_iid etc but I think that it should be doable.

As a result IConfigurable could be declared like this:

class IConfigurable
{
    Q_OBJECT_INTERFACE("com.example.interfaces.IConfigurable")
    Q_PROPERTY(QString config READ config WRITE setConfig NOTIFY configChanged)
public:
    virtual QString config() const = 0;
    virtual void setConfig(const QString &config) = 0;
signals:
    void configChanged(IConfigurable *obj, const QString &config);
};

This way it could be used like the full QObject in connect calls and interfaces already could declare what properties are to be supported by implementing classes without having to state this again for each class.

Another benefit is that it makes issue 20616 obsolete.