Not sure why I'm getting
```
Fehler beim Abfragen der Syncthing-Konfiguration: Error transferring http://127.0.0.1:8384/rest/system/config - server replied: Forbidden
URL der Anfrage: http://127.0.0.1:8384/rest/system/config
```
one one of my setups but this kind of error can likely be ignored shortly
after the start similar to other types of errors.
* Do *not* build Syncthing in addition as standalone executalbe
* Explose instead all of Syncthing's commands via the library
interface
* Make all of Syncthing's commands (including `serve`) accessible
via Syncthing Tray's executable
* Remove copied code for directory creation and instead use
upstream's code directly
* Do not blindly override existing auto start entry
* Warn if an auto start entry exists but points to a different executable
* Allow removing such an entry explicitly
* Avoid overriding argv/argc via `CMD_UTILS_CONVERT_ARGS_TO_UTF8` in
Windows-specific code when processing arguments from a 2nd instance
* Move the other startup code to main as well as they are not needed when
processing arguments from a 2nd instance
* Improve debug logging
* Use `waitForBytesWritten()` instead of `flush()` when passing args as
recommended by the documentation
* Avoid use of `bytesAvailable()` as it doesn't work as expected in this
situation on Windows (likely it doesn't really work reliably on all
platforms); calling `readAll()` works and is simpler anyways
* Tested that `--replace` works as well; also the
`waitUntilGone && QFile::exists(fullServerName)` block is entered and if
the previous instance is taking some time it really waits until it is
gone
* Make functions in `main.cpp` static as they are not used by
other units
* Delete the `TrayIcon` via an extra parent object that is
deleted before the `QNetworkAccessManager` is deleted; otherwise
the destruction of `SyncthingConnection` (which aborts pending
replies) might access dangling `QNetworkReply` objects
* Improve error handling in `SingleInstance` code
* Allow to replace the current instance via the new `--replace`
argument; this may be useful when creating an installer/updater
So far the Plasmoid is not covered. It would likely not be very useful
anyways because under GNU/Linux the default icon theme can be determined
from the system and thus the "fallback" default this change is about is not
effective.
In this case the connection from the setup detection is not the correct
one. The connection used to apply the settings should generally be used for
querying the QR-code.
* Remove experimental pinning feature again and instead allow using a
normal window
* Pinning made it inconvenient to close the (frameless) window again
* Pinning required hiding/showing the window which didn't look very
nice (and setting flags directly via `QWindow` didn't work as well)
* As normal application/window positioning issues on Wayland are less
problematic (and those aren't going to be fixed any time soon, if at all)
