kfmclient: Fix recursive invocation and handle association correctly

If 'kcmshell5 componentchooser' is used to set the default web browser to Konqueror, then as well as changing the text/html file association it sets

[General]
BrowserApplication=kfmclient_html.desktop

in kdeglobals. When kfmclient is invoked to open a HTTP URL, whether from the command line or via a service file, ClientApp::createNewWindow() is called which looks at this setting. If the 'browserApp' condition is true (which it will be in this case), the actual command or service setting is ignored and the original URL is simply opened via an OpenUrlJob. The file type association then calls kfmclient again and loops endlessly.

This change splits up the complicated test and handles the two cases appropriately: either launching the external browser (setting starting with a '!') using a CommandLauncherJob, or starting the service (setting not starting with a '!') using an ApplicationLauncherJob. Both of these code paths check that kfmclient would not be called recursively. If this happens, or if the setting is absent or there are problems launching the job, then the client falls through to opening the URL in Konqueror directly. This means that it cannot loop and the URL is opened in the intended application.

Tested with 'kfmclient openURL' with this setting absent, and with the browser default set to Konqueror, an external browser using a service file, and an external browser specified with a command line. The URL is opened in the intended application in all cases.