Inconsistent reporting of `st_nlink`

1. Enable `fuse-overlayfs` for your container config:

```
$ cat ~/.config/containers/storage.conf
[storage]
driver="overlay"

[storage.options.overlay]
mount_program = "/usr/bin/fuse-overlayfs"
```

2. `podman run -it --rm fedora`
In this container image the `/usr/share/crypto-policies/DEFAULT/bind.txt` and `/usr/share/crypto-policies/back-ends/DEFAULT/bind.config` files are hardlinked.

3. Run this command:
```
# stat /usr/share/crypto-policies/DEFAULT/bind.txt
...
Device: 0,125 Inode: 50057153 Links: 1
...
```
Note the device and inode, and the fact that `Links: 1`.

4. Run this command:
```
# stat /usr/share/crypto-policies/back-ends/DEFAULT/bind.config
...
Device: 0,125 Inode: 50057153 Links: 2
...
```
Note that this is the same inode, on the same device, but somehow it has `Links: 2` now.

5. Run this command (which is the same as the first command):
```
# stat /usr/share/crypto-policies/DEFAULT/bind.txt
...
Device: 0,125 Inode: 50057153 Links: 2
...
```
And now note that `Links: 2` as well when accessing the file through the original filename (which used to report `Links: 1` in step 3).

The only think I can think of is that `fuse-overlayfs` reports `st_nlink` as 1 until it "sees" the second hardlink to the file, at which point it updates its opinion to `st_nlink` being 2, and persists that change in some kind of a cache.

Maybe it's doing that to avoid leaking outside information into the container? ie: maybe there are extra hardlinks that the container should not know about?

Either way, this is causing problems with programs inside of the container that attempt to detect hardlinks by collecting `(dev, inode)` values from files that have `st_nlink > 1`.