This partly a preparation for proper multi-PV array support.

The problem was a call seq_monitor(ch, FALSE) inside pvAssign after we
destroy the channel (if one exists). This will always fail (strange I
never noticed that) and as a result dbch->monid would not be reset to
NULL. That in turn means when the channel is re-assigned and connects,
seq_monitor(ch, TRUE) will not do anything because it thinks there is
already a valid subscription.

The fix is to remove the call and instead only reset dbch->monid to NULL.

Instead of using per channel semaphores to check for completion, the
new implementation uses the request pointer. A NULL pointer means that
no request is pending, i.e. either the request was cancelled or it
completed sucessfully or we lost connection to the PV. The CA callback
resets the request pointer before signalling to the state set where the
request originated, that /some/ event happened. This re-uses the the
existing sync semaphore. ASYNC operations no longer use a semaphore at
all, only the SYNC variants do. However, it becomes even more important
to check whether a disconnect happened, since this is "some event", too,
i.e. it causes pending requests to be cancelled.

The standard EPICS severities (NO_ALARM, MINOR, MAJOR, INVALID) should be
reserved for the actual severity of the underlying PV which we get via CA.

I forgot to add the array index to the varId when iterating
over a multi-PV array.

This patch also gets rid of the ugly seq_sync_timeout hack.

This is clearer and more robust than relying on the (incidental)
truth value of a pvStat value.

This brings asynchronous pvGet to the same standard w.r.t. multi-PV
arrays as pvPut. Another slight improvement: in non-safe mode, if
a variable is not assigned to a PV, then return TRUE, so that
when testing in a condition it does not hang forever.

While it was always allowed to use arbitrary expressions for the
argument to delay(), this never worked as one would expect if the
expression depended on e.g. monitored variables. The reason is that
previously the delay expression was evaluated once for all delays
appearing in conditions inside a state when the state was entered.
Later checks whether the delay has expired used the cached delay
value.
Now, delay expressions are evaluated like all other parts of the
state transition condition and seq_delay() takes a double argument
instead of a delay id. As a (transparent) side effect, if the
delay has not yet expired, the minimum time to wait for events is
adjusted. This adjustment is now more precise, since we do not store
the delay but rather the (future) time when the wakeup should happen.
The new implementation makes a lot of code obsolete which has
consequently been deleted:
- type DELAY_ID and all mentions of delay ids
- assignment of delay ids in the compiler
- the special cases FT_DELAY for the delay() builtin and
  the special E_DELAY syntax node type
- generated delay init functions
- seq_delayInit()
- clearDelays() and calcTimeout() in seq_task
- array members delay, delayExpired of struct state_set
  instead there is now double wakeupTime
- member numDelays in various structs
- assign_next_delay_id in the compiler

We issue a warning message in this case, since this is most
probably a logical error in the SNL program.

It is friendlier to just go on than to let the program hang.
Note that this is still a user error and a message is issued
to indicate it.

Must not epicsEventSignal when epicsEventTryWait returns
epicsEventWaitTimeout, since this means we have not yet been called
back by CA. This bug could lead to pvGet/PutComplete erroneously
returning TRUE even though the callback did not yet arrive.

This patch gets rid of most of the pv layer, including all remaining C++
code. Also removed is the C++ test/example code for the pv layer. The
interface (pv.h) is not the same, but similar; mostly it is much simpler
and more statically typed.

If epicsEventTryWait succeeds, there could still be a previous request
pending that has timed out. This happens e.g. if the user code did not
call pvGetComplete resp. pvPutComplete. In that case we must reset the
request pointer to NULL in order to invalidate the request so it gets
ignored whenever it finally arrives.

The problem was that that once a synchronous request times out, the
variable would never recover from the timeout state. This was because
the semaphores would not be signalled on timeout. However, in order
to correctly discard events (i.e. callbacks from CA) that belong to
timed out requests, we have to remember them. This is what the getReq
and putReq arrays in struct state_set are for.

The fix assumes that CA will eventually call the callback for each
accepted request, even if the channel disconnects. If the assumption is
wrong then we have a memory leak.

Now, if you do pvSync(x,ef), where x is an array for which the elements are
individually assigned to a separate PVs, then all the elements get synced
with the event flag, just like if you use the sync clause.

The connection handler now releases all semaphores waiting for an
event on this PV. Furthermore, the pvGet/pvPut[Complete] built-in
functions check the connected status whenever they successfully waited
for such a semaphore.

This patch also fixes a few problems with error handling in these
procedures; for instance, the SYNC versions released semaphores even
in case of timeout, which is definitely wrong.

Each event flag now knows the channels which are synced to it.
This is a singly linked list of channel pointers. Since each channel
can be synced to at most one event flag, we can embed the list nodes
into the channel structure, so no runtime allocation is needed.
The pvSync builtin function must now update these lists, while
ss_read_buffer_selective traverses them.

The fix is to declare efTest and efTestAndClear to be synchronization
points in safe mode. Both now check whether any of the variables sync'ed
with the event flag have been changed (have their dirty flag set) and
update the state set local copy of these variables. This happens
regardless of whether the call is part of a when() condition or inside
an action block.

When pvAssign was used to re-assign an already connected PV, this was
not correctly accounted for and a wrong warning message was issued.

The bug resulted in a crash in pvGet after an initially unassigned
variable gets assigned using pvAssign in safe mode.