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 under $XDG_STATE_HOME (~/.local/state by default),
which scan creates, instead of failing on /var/lib/sfdupes. Root keeps
/var/lib/sfdupes/db.sqlite. sfdupes --help 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
@@ -45,8 +44,9 @@ that stands for a piece of hardware, such as a disk or a terminal. `report`
 prints the file-level duplicates. `trees` prints the duplicate directory trees.
 `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`. On Linux, any other
+user keeps it in `~/.local/state/sfdupes/db.sqlite`. `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
@@ -146,8 +146,9 @@ walk"). As the file `/etc/cron.d/sfdupes`:
 - `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
 
@@ -283,9 +284,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`) 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 least 1. A
@@ -880,7 +881,15 @@ 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 to an absolute path. Otherwise
+  it is `~/.local/state` on Linux and `~/Library/Application Support` on macOS.
+
+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
@@ -920,9 +929,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