Make sure plugins under LTCG get the right flags too.

Change-Id: I51384b4c3ceca25b6e010ccf67fa0f1995cfa557
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Fix linking of sources without LTCG to a static lib with LTCG

Whenever a binary is created and linked against a static lib that was
compiled with LTCG, the final linking step requires the compiler flags
so that the pre-compiled data in the shared library can get properly
compiled.

This could happen for a static build of Qt with LTCG, but also happens
frequently for Qt's own build when linking regular libraries and
applications against QtBootstrap or QtPlatformSupport. The linking fails
when the target is a shared library (example: QtWaylandClient linking
against QtPlatformSupport).

The .prl file actually contains the "ltcg" flag, so the best solution
would actually be to process that flag there and add link_ltcg if any
dependent .prl has "ltcg", but I couldn't find out how to do that.

Change-Id: I4a75a14d1dcb8c2089a427285e25d5555df7d7d3
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Un-tighten the WinRT specific code out of qfunctions_winrt.h

Keep the WinRT specific parts for WinRT only. This commit is a partial
reversal of 67c83f329e7fb6fbf5d8e402f42ea8916c34f01c "Tighten Q_OS_WINRT
ifdefs in qfunctions_winrt.h", which let the WinRT definitions out too
wide.

Strictly speaking, the C++ code that uses
Microsoft::WRL::ComPtr<IAsyncInfo> without the #include is broken. The
forward definition is not enough, but since Visual Studio is also
broken, two wrongs made a right... (MSVC does not implement two-stage
parsing of template code properly). But if you accidentally tried to
compile qfunctions_winrt.h with a non-broken compiler, like GCC (MinGW),
it would correctly complain.

Change-Id: I7591015861d291a82050afe0f4df0cb18b43e23d
Reviewed-by: Andrew Knight <andrew.knight@theqtcompany.com>
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@theqtcompany.com>
Fix placement of QT_{BEGIN,END}_NAMESPACE in qfunctions_winrt.h

Those functions weren't getting properly namespaced. Even if we're
testing WinRT namespaced builds, it wouldn't catch this mistake: those
functions would simply all be in the global namespace. I guess we don't
have a "namespace cleanliness" test.

Change-Id: I2d3d09dc66dad476563dbf51c171683be155ebfd
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@theqtcompany.com>
Reviewed-by: Andrew Knight <andrew.knight@theqtcompany.com>