QNetworkInfo: Document threading restriction

Specifically on Windows we use COM, which requires being
de-initialized in the same thread as it was initialized.
Given that QNetworkInfo is a GLOBAL_STATIC with a qAddPostCondition
(iirc APPLICATION_STATIC was not yet implemented at the time) to
delete the backend when qApp is destructed, we need to cope with
destruction happening on the main thread.
If the backend is loaded on a secondary thread, the thread may
have shut down, or we may not otherwise be able to rely on
emitting Queued emissions to perform the destruction.
Conversely we also can't trivially move the construction to the
application thread (eg. using BlockingQueued emission during first load)
because we may cause a deadlock.

This leaves us with just documenting where the first load should happen.

Fixes: QTBUG-133644
Pick-to: 6.8 6.5
Change-Id: I7f52e884151c6c24acc34f1112faabc897d9b0f9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 6ad2918de4a300d11472edcafe62f07ae2f63cd8)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>

src/network/kernel/qnetworkinformation.cpp

@@ -419,6 +419,12 @@ QNetworkInformationBackendFactory::~QNetworkInformationBackendFactory()
     If you destroy and re-create the QCoreApplication object you must call
     load() again.
 
+    \note Because the class is a singleton while also relying on
+    QCoreApplication, QNetworkInformation should always first be loaded
+    in the same thread as the QCoreApplication object. This is because the
+    object will also be destroyed in this thread, and various backend-specific
+    components may rely on being destroyed in the same thread as it is created.
+
     \sa QNetworkInformation::Feature
 */