The QNetworkReply objects created in
CustomSchemeHandler::requestStarted() are never destroyed, not even at
KDevelop exit, even though they are used for a few seconds at most.

From the documentation for QNetworkReply::finished():
  Note: Do not delete the object in the slot connected to this signal.
  Use deleteLater().

From the documentation for QWebEngineUrlRequestJob::reply():
  The user has to be aware that device will be used on another thread
  until the job is deleted. In case simultaneous access from the main
  thread is desired, the user is reponsible for making access to device
  thread-safe for example by using QMutex. Note that the device object
  is not owned by the web engine. Therefore, the signal
  QObject::destroyed() of QWebEngineUrlRequestJob must be monitored.
  The device should remain available at least as long as the job exists.
  When calling this method with a newly constructed device, one solution
  is to make the device as a child of the job or delete itself when job
  is deleted, like this:
    connect(job, &QObject::destroyed, device, &QObject::deleteLater);

Destroy CustomSchemeHandler's QNetworkReply object once it is finished
and the QWebEngineUrlRequestJob object that uses it is destroyed.

Qt WebEngine uses the QNetworkReply object on another thread. But our
HelpNetworkReply appears to be free of data races because it logically
finishes in the constructor. It is possible to call setFinished(true)
and emit finished() in a 0 ms timer single shot from HelpNetworkReply's
constructor, but such changes may cause a regression with Qt WebKit.