More robust locking for filecontent_metadata

Improve the locking code used for the git repo in filecontent-metadata:

• record which process locked when from where, and in case the lock cannot be obtained, report who is currently holding the lock
• when failing to acquire a lock, check whether the lock should be considered stale, and if so, remove it
  • stale locks are those with a content that matches expectations, created by a process on the same host as the current one, and no process with the recorded pid is present
• explicitly drop acquired locks in case of filesystem errors
• cleanup traceback in case the lock could not be acquired (no more exception during exception), use TimeoutError instead of RuntimeError

To do

• ci-test against lhcb-master
• ci-test against lhcb-sim11