test: sched: don't require error on max_delay=0xffff in Schedule

It's not a L4_Time_t.
sched: fix setting max_delay

It's an ordinary number of microseconds, not a period-format L4_Time_t; and
furthermore the 0xffff value should keep it from being set at all.
test: ipc: add test for preemption on active receive

This test, and its active-send sibling, further need some way to confirm that
the active form is what actually happened.
ipc: move sender state transitions out of ipc_send_half()

The problem being solved is this: there are actually three kinds of IPC that
ipc_send_half() is used for. First, IPC from kth to userspace; then IPC from
kernel to userspace for pagefaults and exceptions; and finally IPC between
userspace threads.

These three contexts handle success differently. For example, all but the
pf/exn mode go to scheduler on preemption, and the latter always returns to
the IPC peer. In this light the way ipc_send_half() always shifts the caller
into R_RECV is unnecessarily general; it also causes a bunch of control-flow
dependency in the sq_update_thread() call.

Another changeset like this will follow for ipc_recv_half(), eventually.
sched, thread: generate & consume the kernel_preempt_pending flag

It's generated by might_preempt(), called from thread_sleep() in its
thread_wake() mode, and from the ->R_RECV state transition in ipc_recv_half();
and consumed by return_from_exn(), wrapped in a syscall-friendly way in the
new return_to_preempt(). Based on a few of the scheduling tests executed by
hand, it seems to detect the preemption condition exactly as it should.

return_from_exn() will now switch to the preempting higher-priority thread,
refilling its quantum exactly as schedule() would've done to a single-ready
priority band. There's a wart left: current == next is permitted though it
really shouldn't happen.

This changeset also removes explicit preemption-sniffing from int_latent(),
where it doesn't properly belong in.
ipc: remove explicit preemption from ipc_{send,recv}_half(), ipc_resume()
sched: work around self-preemption in schedule()

... by noticing that the potential chosen thread isn't eligible to run anymore
(or at all), and re-entering the function. No more calls to check_preempt():
it's useless anyway when current == scheduler_thread .
test: ipc: correct use of L4_PreemptionPending() in recv_preempt

It also clears the flag, which while somewhat odd doesn't make the test any
worse even if it was wrong before this changeset.

Also check that the "delay-preemption" flag is cleared on short delay, because
it's possible.
sched: implement delayed preemption on wakeup

With this, send_preempt and recv_preempt pass fully.