fdrop_locked() and FILE_LOCK() vs. Giant

The FILE_LOCK() implementation uses "pool mutex" under the hood, which
means it should only be used as a leaf level mutex.  The fdrop_locked()
code wants to be called with FILE_LOCK() held, but the fdrop_locked()
implementation calls mtx_lock(&Giant) before calling FILE_UNLOCK().  In
addition to violating the proper usage of the "pool mutex", there is
also the potential for a lock order violation.  The close()
implementation grabs Giant and eventually calls fdrop(), which calls
FILE_LOCK() immediately before calling fdrop_locked().  If another
caller of fdrop_locked() calls FILE_LOCK() without grabbing Giant first,
then the lock order will be reversed when fdrop_locked() grabs Giant.

It looks like fdrop_locked() should require that Giant be grabbed by the
caller before fdrop_locked() is called.