WM_CHAR creates unwanted keyboard event - activating shortcut

This is probably best illustrated by an example. In the following app, we create a shortcut that handles F5 key presses:
 

#include <QApplication>
#include <QLabel>
#include <QShortcut>

int main(int argc, char **argv)
{
    QApplication app(argc, argv);

    QLabel content("Some Text");
    content.setContentsMargins(10, 10, 10, 10);
    QShortcut shortcut(QKeySequence("F5"), &content);
    QObject::connect(&shortcut, &QShortcut::activated, []() {
        qDebug() << "ACTIVATED";
    });

    content.show();
    return app.exec();
}

To reproduce the issue, do the following:

• Select a keyboard layout with dead keys (tested with US-International and German)
• Press F5 once (this is important) - you should see ACTIVATED in the console
• Press any accent character (' " ` ~ ^)
• Press t - you should see ACTIVATED in the console again (unwanted)

When logging the messages (msg; wp = wParam, lp = lParam) in QWindowsKeyMapper::translateKeyEvent, you'll get the following:

{msg=0x100 (= WM_KEYDOWN) wp=0x74 (= VK_F5)    lp=0x00000000003f0001}
{msg=0x101 (= WM_KEYUP)   wp=0x74 (= VK_F5)    lp=0x00000000c03f0001}
ACTIVATED
{msg=0x100 (= WM_KEYDOWN) wp=0xdd (= VK_OEM_6) lp=0x00000000000d0001}
{msg=0x101 (= WM_KEYUP)   wp=0xdd (= VK_OEM_6) lp=0x00000000c00d0001}
{msg=0x100 (= WM_KEYDOWN) wp=0x54 (= T key)    lp=0x0000000000140001}
{msg=0x102 (= WM_CHAR)    wp=0x74 (= 't')      lp=0x0000000000140001}
{msg=0x101 (= WM_KEYUP)   wp=0x54 (= T key)    lp=0x00000000c0140001}
ACTIVATED

As you can see, VK_F5 has the same value as 't' in ASCII (and thus Utf16). So technically, the same bug can be triggered by listening for F4 and pressing 's' (and so on).

In QWindowsKeyMapper::translateKeyEventInternal, which gets called for key events (including WM_CHAR), the key is extracted out of the wParam (wp), which is wrong for WM_CHAR messages (MS docs) as it contains the Unicode character that should be typed (which is correctly extracted in messageKeyText).