Keep a non-root user's database in the XDG state directory (closes #171)

Without SFDUPES_DATABASE, a user other than root now uses
sfdupes/db.sqlite in the XDG state directory (~/.local/state by
default) instead of failing on /var/lib/sfdupes. scan creates the
missing directories there with mode 0700, as the XDG Base Directory
specification asks. An XDG_STATE_HOME that is not an absolute path is
a fatal error for every subcommand. Root keeps
/var/lib/sfdupes/db.sqlite. The help of sfdupes and of scan, and
README, say where the database is. Adds github.com/adrg/xdg, the
decided XDG library.

Model: opus-5-5

README.md

@@ -29,7 +29,6 @@ first look at a new machine with one command.
 
 ```sh
 make build
-export SFDUPES_DATABASE="$HOME/.local/share/sfdupes/db.sqlite"
 ./sfdupes scan /srv
 ./sfdupes report > dupes.tsv
 ./sfdupes trees > dupetrees.tsv
@@ -47,8 +46,10 @@ Both cover the whole database, or only the paths given after them, as in
 `sfdupes report /srv/photos`. `info` prints the database's path, size and record
 count.
 
-The database is `/var/lib/sfdupes/db.sqlite` unless `SFDUPES_DATABASE` names
-another file. The first `scan` creates it.
+Root keeps the database in `/var/lib/sfdupes/db.sqlite`. Any other user keeps it
+in `sfdupes/db.sqlite` in the XDG state directory, `~/.local/state` by default
+on Linux. `SFDUPES_DATABASE` names another file (see "Location"). The first
+`scan` creates the database.
 
 `report`, `trees` and `info` write their data to stdout. Progress, warnings and
 errors go to stderr. stdout and stderr are a program's two output streams. The
@@ -155,8 +156,9 @@ point of each disk at or below `/srv` with its own `mountpoint -q`, joined with
 - `report`, `trees` and `info` need only read access to the database. The umask
   is the setting that removes permissions from the files a process creates.
   Under the usual umask of `022`, the first scan creates the database readable
-  by every user. An unprivileged user can then run those three commands against
-  root's database.
+  by every user. Another user can then run those three commands against root's
+  database, with `SFDUPES_DATABASE=/var/lib/sfdupes/db.sqlite` before the
+  command.
 
 ### Reading the reports
 
@@ -295,9 +297,9 @@ The reference below is also the program's specification.
 ### Settings
 
 - `SFDUPES_DATABASE` names the database file. When it is unset or empty, the
-  database is `/var/lib/sfdupes/db.sqlite`. There is no command-line flag for
-  it. The path names the file exactly, whatever characters it holds. A relative
-  path is relative to the working directory.
+  database is at its default path (see "Location"). There is no command-line
+  flag for it. The path names the file exactly, whatever characters it holds. A
+  relative path is relative to the working directory.
 - `--workers N` (`scan`, `dwim`) sets how many directories `scan` reads at once
   while it lists the trees. It also sets how many files `scan` reads at once
   while it hashes them. The default is the number of CPUs. `N` must be at
@@ -977,7 +979,22 @@ All five subcommands work on one SQLite database file.
 #### Location
 
 The database is the file named by `SFDUPES_DATABASE`, when that is set and not
-empty, and otherwise `/var/lib/sfdupes/db.sqlite`.
+empty. Otherwise it is at its default path, which depends on the user:
+
+- For root, it is `/var/lib/sfdupes/db.sqlite`.
+- For any other user, it is `sfdupes/db.sqlite` in the XDG state directory. That
+  directory is `$XDG_STATE_HOME` when that is set and not empty. Otherwise it is
+  `~/.local/state` on Linux and `~/Library/Application Support` on macOS. An
+  `XDG_STATE_HOME` that is not an absolute path is a fatal error, exit 1, for
+  every subcommand. The error names `XDG_STATE_HOME`.
+
+`scan` creates each missing directory on the way to the database with mode 755.
+At the default path of a user other than root, it uses mode 700 instead, as the
+XDG Base Directory specification asks. Other users cannot enter a directory with
+mode 700, so they cannot read a database in it.
+
+All five subcommands use the same default, so a user's `report` reads the
+database that user's `scan` wrote.
 
 Each subcommand prints one line on stderr naming the database it uses, before
 anything else and whether or not stderr is a terminal. The line gives the path
@@ -1017,9 +1034,9 @@ Only one `scan` at a time can hold the lock.
 - For its whole run, `scan` holds a lock on a lock file beside the database. The
   lock is taken with the `flock(2)` system call, a request a program makes to
   the kernel, and only one process can hold it. The lock file's name is the
-  database's path, with symlinks resolved, plus `.lock`. By default that is
-  `/var/lib/sfdupes/db.sqlite.lock`. A path through a symlink names the same
-  lock file.
+  database's path, with symlinks resolved, plus `.lock`. For root, by default,
+  that is `/var/lib/sfdupes/db.sqlite.lock`. A path through a symlink names the
+  same lock file.
 - `scan` takes the lock before it walks the filesystem or opens the database.
   Just before that, it creates the database file, empty, if it is missing. So
   the lock file is named the same way before the first scan as after. A symlink