Feature: Detect hard links

Running the following commands

```Bash
mkdir tmp
ls -hs ./tmp
wget --quiet https://www.gutenberg.org/files/1661/1661-0.txt --output-document=./tmp/sherlock.txt
ln ./tmp/sherlock.txt ./tmp/sherlock-link.txt
ls -hs ./tmp
```

Will produce a 600 KiB file `sherlock.txt` and a hard link `sherlock-link.txt`.
`diskonaut` currently detects these 2 as different files but deleting either file will not free any disk space (beyond a little metadata).
This is similar to the problem of issue #26 where the expectation of xG of deleted data = xG of more usable space proves incorrect.

This problem is typical of hard links (see `ln`'s behavior) but it would be cool if `diskonaut` could deal with them nicely.

## UI idea

Put upper and lower bounds on disk-space before running the slower process of detecting the details of hard-linked files.
By checking for files with a link-count of 1, you can identify non hard linked files.
If you assume that all hard linked files are used outside the current folder (this assumption may be modified for the root directory perhaps) than you get a lower bound of space freed upon deletion.
If you assume that all hard linked are within a directory, you get an upper bound of space freed upon deletion (this is the current behavior of `diskonaut`)

1G < ?G < 2.4G

Reproduce the hard-link example using the listed mkdir, wget, ln, and ls commands, then review issue #26 for the related disk-space expectation. The issue does not name implementation files or tests; clarify the intended lower and upper bounds and what handling hard-linked files should mean before defining completion.

Written by the indexing model from the issue text.