Add kernel-layer support for chflags checks, remove (most) from the VFS layer.

Add kernel-layer support for chflags checks, remove (most) from the VFS layer.

Give nlookup() and nlookup_va() the tools to do nearly all chflags related
activities.  Here are the rules:

Immutable (uchg, schg)

    If set on a directory no files associated with the directory may
    be created, deleted, linked, or renamed.  In addition, any files open()ed
    via the directory will be immutable whether they are flagged that
    way or not.

    If set on a file or directory the file or directory may not be
    written to, chmodded, chowned, chgrped, or renamed.  The file can
    still be hardlinked and the file/directory can still be chflagged.
    If you do not wish the file to be linkable then set the immutable bit
    on all directories containing a link of the file.  Once you form
    this closure no further links will be possible.

    NOTE ON REASONING:  Security scripts should check link counts anyway,
    depending on a file flag which can be changed as a replacement for
    checking the link count is stupid.  If you are secure then your closures
    will hold.  If you aren't then nothing will save you.

    This feature is not recursive.  If the directory contains
    subdirectories they must be flagged immutable as well.

Undeletable (uunlnk, sunlnk)

    If set on a file or directory that file or directory cannot be removed
    or renamed.  The file can still otherwise be manipulated, linked, and
    so forth.  However, it should be noted that any hardlinks you create
    will also not be deletable :-)

    If set on a directory this flag has no effect on the contents
    of the directory (yet).  See APPEND-ONLY on directories for what
    you want.

Append-only (uappnd/sappnd)

    If set on a directory no file within the directory may be deleted or
    renamed.  However, new files may be created in the directory and
    the files in the directory can be modified or hardlinked without
    restriction.

    If set on a file the file cannot be truncated, random-written, or
    deleted.  It CAN be chmoded, chowned, renamed, and appended to
    with O_APPEND etc.

    If you do not wish the file to be renameable then you must also
    set the Undeletable flag.  Setting the append-only flag will ensure
    that the file doesn't disappear from the filesystem, but does not
    prevent it from being moved about the filesystem.

Security fix - futimes()

    futimes() could be called on any open descriptor.  Restrict
    it to just those files you own or have write permission on.

Security fix - Hardlinks

    Users can no longer hardlink foreign-owned files which they do not
    have write access to.  The user must now have write permission on
    the file being hardlinked or the user must own the file, or be root.

Security fix - fcntl()

    fcntl() can no longer be used to turn of O_APPEND mode if the file
    was flagged append-only.

NOTE - DIFFERENCES WITH FREEBSD

    * Append-only on directories

    * Immutable on directories to control set-in-stone & hardlinking

    * Immutable files can be hardlinked on DragonFly, not on FreeBSD.

    * User must be the owner of the file or have write access to the
      file being hardlinked.