QLockFile's PID clash resolution is unsuitable for long-term operations

Consider the following situation:

• QLockFile::setStaleLockTime(0) is called for a longish operation, as recommended in the documentation.
• QLockFile obtains a lock for the process P with PID X.
• P crashes, and the lockfile doesn't get deleted.
• A process Q is started and gets the PID X.
• P is started again and tries to obtain the lock.
• This attempt fails, because there's already a process with PID X running.

QLockFile's attempt of resolving PID clashes revolves around the stale lock timeout. This cannot work for long-lived operations that get a zero timeout.

QLockFile must retrieve the process name that belongs to PID X and compare it with qAppName(). If those are different, then the lock file is stale.