POSIX lock resource limit part 3/4

POSIX lock resource limit part 3/4

This splits "struct lockf" into the general book-keeping of ranges and
blocked request and the "struct lockf_range" which constists of the data
for a specific range. Adjust the interface of lf_advlock to remove one
level of pointer indirection and embedded "struct lockf" directly in the
inodes. Don't mess with wait channels any more.

Change the algorithm for determing locks to a more direct approach, which
both simplifies the lock acquisition and proper book-keeping of the number
of ranges currently used. The later is necessary to prevent local resource
exhaustion.

The code is not fully malloc block-safe, but as good or bad as
the old code.

Add the kernel part of the posixlocks rlimit. This is the maximum number of
POSIX lock ranges any user can acquire. These numbers are tracked for each
user and process and checked at lock/unlock time. If a process changes uid,
its locks are transfered to the new uid which can effectivly boost that
number above the limit.

This is based on the patch set from Devon H. O'Dell <dodell@sitetronics.com>
for the general infrastructure with some adjustment to better integrate with
the new lockf code.