fsnotify: Rework inode tracking

Hello!

This patch set reworks how fsnotify subsystem tracks inodes. So far we have
held inode references from notification marks (connectors of list of
notification marks to be more precise). This has three issues:

1) Placing a notification mark pins inode in memory. Since inodes are
relatively big objects, users could pin significant amount of kernel memory
by this. This then requires administrators to configure suitable limits on
maximum amount of notification marks each user can place which is cumbersome.

2) During filesystem unmount we have walk a list of all inodes for the
superblock to drop these inode references. This is either slow (when we do
it before evicting all other inodes) or opens nasty races (when fsnotify()
can run after dcache for the superblock has been evicted).

3) Since sb global inode list is a noticeable contention point we are trying
to transition its users to something else so that we can eventually get rid
of it.

In this patch set, fsnotify subsystem tracks notification marks attached to
inodes in a specialrhashtable indexed by inode identifier. This way we can stop
holding inode references and instead disconnect notification marks from the
inode on inode eviction (and reconnect them when inode gets loaded into memory
again). Credit for the original idea of this tracking actually goes to Dave
Chinner.

The patches are so far incomplete - I still need to implement proper handling
for filesystems where inode number isn't enough to identify the inode. isofs
is provided as a sample how such support will look like for these filesystems.

Also we need to decide what to do with evictable notification marks. With the
patches as is they are now never evicted. This makes sense because the main
reason behind evictable marks was to avoid pinning the inode. On the other
hand this *might* surprise some userspace - definitely it breaks couple of LTP
tests we have for evictable marks.

Overall the patches passed some basic testing with LTP so they shouldn't be
completely wrong but there could be bugs lurking so handle with care ;).
I'm sending the patches for comments to the approach and whether people find
this approach acceptable.

								Honza