VxWorks and RTEMS-4.9 return -1 on error, while Linux returns SEM_FAILED
which is NULL.

The timeout property of a lowcal variable is redefined so as to refer to the
time between sending a request and receiving a response. In other words, the
time spent inside the send queue is not counted. Implementation-wise, this
means we set the timeout counter when dequeueing the request, not when we
enqueue it.

This change avoids spurious errors (PROT_UMSG or PROT_2LATE) that happen
when a varset has many multiplexers enqueued and a pending request times out
due to a send error. In this case, enqueued requests will be sent (because
the writer has higher priority than the timer) and then promptly times out;
the response, when it arrives, will then cause one of the two error message
above.

Another advantage of the new scheme is that the timeout can now be
configured without knowing how many multiplexers there are.

Finally, the implementation is simplified, since we no longer need to remove
elements from the queue, except the head. The functions unqueue and
varsetq_remove are no longer used and have been removed. We could even go
back to using a singly linked list for the send queue.

This reflects changes in the sci API and enables applications to these changes
into account.

For compatibility (e.g. with other protocols) gps_write still uses
sci_write_inhibit when this flag is set, but for lowcal we always want to
use the normal sci_write.

The previous implementation of write_notify had a number of problems that
led to spurious timeouts and even deadlocks. One problem was the assumption
that when the time due from the last call to write_notify is in the past,
then the alarm must be inactive. This is unreliable, because there is always
some extra delay between the time due and the actual call of the callback. A
second problem is that write_notify_cb was called directly in some places,
circumventing the bookkeeping (last_notify) inside write_notify.

We now check directly with a boolean flag whether an alarm is active or not.
Also, all notify calls are now via write_notify.

Unfortunately it appears that this is not yet a full solution. There are
still timeouts (especially with the faster CPU board) and it usually takes
about 30 seconds to recover from this condition.

It turned out that this is needed for the mvme5500. The rather unintuitive
fact that the timeout needs to be longer for a faster CPU can be explained
by observing that the faster CPU can send more requests, thus gets more
responses, and response messages have higher priority (lower CAN object ids).