When creating a new thread, we unconditionally copy td_frame from the
creating thread.  For threads which never return to user mode, this is
unnecessary since td_frame just points to the base of the stack or a
random interrupt frame.

If KASAN is configured this copying may also trigger false positives
since the td_frame region may contain poisoned stack regions.  It was
not noticed before since thread0 used a dummy proc0_tf trapframe, and
kernel procs are generally created by thread0.  Since commit
df8dd602, though, we call
cpu_thread_alloc(&thread0) when initializing FPU state, which
reinitializes thread0.td_frame.

Work around the problem by not copying the frame unless the copying
thread came from user mode.  While here, de-duplicate the copying and
remove redundant re(initialization) of td_frame.

Reported by:	syzbot+2ec89312bffbf38d9aec@syzkaller.appspotmail.com
Reviewed by:	kib
Fixes:		df8dd602
MFC after:	2 weeks
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D32057