Fix a vnode lock leak in vm_fault_hold().

[markj]

Summary

Suppose the fault handler sleeps for an (exclusive) vnode lock. When it
wakes up, it does a "goto RetryFault" with the lock held. If the
subsequent map lookup fails, we may return with the lock held since no
unlock_and_deallocate() call is present in that error path.

We cannot call unlock_and_deallocate() unconditionally in this path,
since the fault state may not yet be fully initialized and we don't want
to waste cycles initializing it just for this rare error case.
Furthermore, we generally release resources before a "goto RetryFault",
and unlock_and_deallocate() is not idempotent. Therefore, I added a call
to vput() rather than unlock_and_deallocate() in the error case.

Test Plan

We've been seeing this lock leak occasionally in stress tests,
presumably due to an application bug. For some reason, it's only
been happening in our "BSD refresh" branch, which brings our
OS up-to-date with respect to FreeBSD.

I added an assertion to the error case for the vm_map_lookup() call
to confirm the scenario I described above.