Rename tdq_ipipending and clear it in sched_switch().

[markj]

Summary

Otherwise sched_preempt() is too fragile. tdq_notify() only raises an
IPI after it adds a new thread to the remote CPU's run queues, so any
switch on the remote CPU once the tdq is unlocked will satisfy the
preemption request.

This fixes a subtle regression from r355311. Suppose a thread is
interrupted by IPI_PREEMPT after decrementing critnest to 0 and before
handling td_owepreempt != 0. sched_preempt() will acquire the thread
lock, and thread_lock() may call spinlock_exit() in its slow path, which
can trigger td_owepreempt handling and cause a switch. The interrupted
thread may then resume on a different CPU, leaving tdq_ipipending set
and thus preventing any further preemptions.

[markj]

In fact, this was a problem even before r355311: bhyve briefly enables interrupts after a vmexit caused by a host interrupt and before calling the ISR. If the vcpu threads are not pinned, one may be preempted during this window and migrate, leaving tdq_ipipending set forever. r355311 apparently just made the problem easier to hit.