Using the inode numbers as the nodeid causes problems
when the fs reuses inode numbers. This is the case with
any overlay filesystem that is backed by ext4 like the
loopback example or gocryptfs.

We already had the expSleep() and re-add hack,

	7090b027 fs: wait out apparent inode type change
	68f70527 fs: addNewChild(): handle concurrent FORGETs

to mitigate some of the problems (at the risk of deadlocking
forever), but I could not find a way to work around the following
case uncovered by fsstress:

The kernel expects a fresh nodeid from MKDIR (see #372 for a
debug log).

This is now guaranteed by passing the O_EXCL to addNewChild().
However, this also means that the hard link detection must
happen in addNewChild() as opposed to newInodeUnlocked()
before. The expSleep and re-add hacks are no longer needed
and have been dropped.

This survived 24 hours (42587 iterations) of fsstress testing.
Tested was the loopback example running on top of ext4 on
Linux 5.8.10.

Fixes https://github.com/hanwen/go-fuse/issues/372 .

v2: Rename inoMap -> stableAttrs, nodeidMap -> kernelNodeIds
    acc. to feedback from Han-Wen.
v3: initialize Inode.nodeId early
v4: drop leftover file stash.txt

Change-Id: Ibb36a886f15d48727daa10b9717ea88e45a6b8af