Optimisations to the pdu queues

When making many concurrent requests (as is likely in any performance
criticial application), the use of SLIST_REMOVE and SLIST_ADD_END are
a severe bottleneck because of their linear search.

I considered using a double-linked list but it was unnecessary to
allocate the additional memory for each list entry.

Instead, continue to use a single-linked list but retain:

* a pointer to the end of the list; and
* a pointer to the previous entry during a linear search.

The former would makes append operations O(1) time, and the latter
does the same for removal. We can do this because removal only happens
within the linear search, and there is no random access to the queue.
Ensure the next pointer is correct

Fixes a bug where the next pointer was not being explicitly set. We
were ok much of the time due to zero-filled memory, and also we need
this if the same pdu is re-queued.
Track waiting requests in a hash table, by xid

NFS servers can respond to requests in any order, and they do. In our
tests there is also some clustering to the responses; it could be
because eg. requests are served synchronously if the data is in the cache.

Introduce a hash table so that we are able to find the pdu quickly in
all cases, assuming random distribution of the responses.
Merge branch 'xid-hash'