aufs: bugfix, removed /proc/PID/fd/N

Before this commit, aufs checks the existence of the opening file on a
branch, since any file cannot be opened newly once it is removed. But it
does harm when the file is opened via /proc/PID/fd/N. Though procfs
users can open a file even if it is removed.
So this commit skips the check when opening a file.

Interestingly, any removed directory (instead of a regular file) cannot
be opened even using procfs. I confirmed it on ext2, but I am not sure
whether this behaviour is intentional or not.
Anyway aufs simply follows the behaviour on ext2.

Strictly speaking, aufs doesn't follow it when the removed file is
chmod/chown-ed via procfs. Ext2 supports it, but aufs doesn't.
I don't think it a big problem since we have fchmod/fchown. With these
systemcalls, users can operate the opened file even if it is removed.

Nfs requires special handling since a removal on NFS is a "silly-rename"
and the name is still hashed and the inode has link count 1.

Note that aufs UDBA feature is related to this open behaviour.

Reported-by: Guan Xin <guanx.bac@gmail.com>
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
aufs: tiny comment

Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
aufs: tiny, update year in copyright

Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
Merge remote-tracking branch 'aufs3-standalone/aufs3.9/00base' into aufs3.9/10static
aufs: tiny, eliminate the rich sentences

Simply follow the style of other files, since aufs3-linux.git already
has COPYING file.

Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
Merge branch 'aufs3.9/10static' into aufs3.9/11proc_map
Merge branch 'aufs3.9/11proc_map' into aufs3.9/18public