Implement proper locking of triblerd.lock file

[kozlovsky]

Right now, despite the name, there is no locking of the triblerd.lock file. The file stores a process ID of the running core instance. Tribler tries to determine if the process was already terminated due to a crash, and the algorithm for this is not 100% reliable. For example, sometimes, the Tribler process that ApplicationTester runs crashes and leaves the triblerd.lock file. After that, ApplicationTester cannot run Tribler, as it assumes that the core is already running and refuses to start with the message 'Core is already running, exiting'. In that case, manual intervention is sometimes necessary to delete the obsolete triblerd.lock file.

It may be better to use an actual file locking, so if it is possible to acquire a lock on the file, it is clear that the previous Tribler process is already terminated.

To implement proper file locking, we can create a small SQLite database and use it as a lock file. Another option is to use a separate library such as filelock. I prefer to use SQLite, as in that case, we rely on the same lock implementation that we already implicitly use in the main database. This way, we can expect fewer surprises on different platforms, and also it allows us in the future to store the detailed journal of Tribler restarts in the same file, which can be helpful to debug some problems.

[drew2a]

the triblerd.lock has been removed here #7212