CFR: Fix a panic in userspace dtrace

[Will Andrews]

Diff: http://people.freebsd.org/~will/patches/fix-fasttrap-panic.diff

Commit log:

	Fix a panic in userspace dtrace.
	
	The bug here is that the proc lock is already held in the case of
	fasttrap_fork(), which then calls proc_ops(), which tries to hold
	it again.
	
	Upon inspection, every other consumer of proc_ops() has already
	placed a hold and then dropped the proc lock.  Change fasttrap_fork()
	to match these semantics, which also happen to mirror Solaris.
	Change proc_ops() to assert that the proc object is held and unlocked,
	rather than executing a hold/rele cycle itself.
	
	Note: fasttrap_fork() is only ever called if an userspace program
	being dtrace'd happens to fork().  So this bug doesn't apply if you
	are dtrace'ing a userspace process that doesn't fork.
	
	Also, at least for ztest, userspace dtrace is still unusable because
	when the child process exits, both dtrace and ztest appear to spin
	forever.  The dtrace process doesn't appear to do anything; the ztest
	process can't be attached via gdb since it's already being ptrace()'d
	by dtrace.  This will require more investigation to fix.


The commit log is a bit dated; I believe that more recent changes by
gibbs at fixed the latter issues.

Thanks,
--Will.