With the rebasing of Xenomai kernel threads over the regular Linux
kthreads, we just can't guarantee synchronous deletion with
xnthread_thread_cancel() anymore. The killed thread will have to reach
a cancellation point later for the request to be actually fulfilled,
so that it may wrap up and exit gracefully linux-wise.

This is actually safer, because kernel threads may associate data to
the wait context before suspending, and certainly don't want to be
wiped out, without being allowed to do the wrap up, thus potentially
leaving stale data.

e.g. we should allow this:

list_add(&myself, &some_q);
xnthread_sleep_on()
list_del(&myself);
...
xnthread_test_cancel();

To this end, this patch removes all cancellation points from
xnthread_suspend(), expecting the Xenomai kernel threads to check for
pending termination requests via a call to xnthread_test_cancel(),
from within their work loop.

In addition, the xnthread_prepare/finish_wait() calls have been
replaced by the xnthread_prepare/complete_wait() pattern, to be used
as follows:

consumer:
	xnthread_prepare_wait(&wc);
	info = xnsynch_sleep_on(&sync, ...);
	if (info) {
	   /* process XNRMID, XNBREAK, XNTIMEO as usual. */
	} else {
	     /*
	      * Resource obtained. In addition,
	      * xnthread_wait_complete_p(&wc) may be called to make
	      * sure xnthread_complete_wait(wc) was issued for the
	      * wait context, assuming forced unblocks may happen,
	      * independently of XNRMID|XNBREAK|XNTIMEO
	      * (not recommended though).
	      */
	}

producer:
	thread = xnsynch_wakeup_one_sleeper(&synch);
	wc = xnthread_get_wait_context(thread);
	/* Post resource. */
	xnthread_complete_wait(wc);
	xnsched_run();