Name the scan lock file from the database's resolved path (closes #101)

The lock file was the configured database path with .lock appended, so
a scan reaching the database through a symlink to it locked a different
file and ran alongside a scan holding the lock through the real path.
The lock file is now named from the database's path with symlinks
resolved. Before the database exists, its directory is resolved and the
file name joined to it, so the error names the same lock file either
way. testDBPath resolves its temp dir, so lock errors name the expected
path where the temp dir is itself reached through a symlink.

Model: opus-5-5

README.md

@@ -271,9 +271,12 @@ All three subcommands operate on a single SQLite database file:
   error (exit 1) telling the user to run `scan` first.
 - Only one `scan` runs against a database at a time. For its whole run, `scan`
   holds an exclusive `flock(2)` lock on a lock file beside the database, named
-  by appending `.lock` to the database path (`/var/lib/sfdupes/db.sqlite.lock`
-  by default), taken before it walks the filesystem or opens the database. A
-  second `scan` against the same database does not wait: it fails at once with a
+  by appending `.lock` to the database's path with symlinks resolved
+  (`/var/lib/sfdupes/db.sqlite.lock` by default), taken before it walks the
+  filesystem or opens the database. Every path to one database, through a
+  symlink to the file or to a directory above it, names the same lock file.
+  Before the database exists, only its directory's path is resolved. A second
+  `scan` against the same database does not wait: it fails at once with a
   one-line error naming the lock file and exits 1, without walking anything or
   opening the database, and the running scan carries on. The lock file is
   created on first use, open to its owner only, and left in place: a leftover