Add some utilities to support 64-bit math operations on platforms that do not support long long types.  Not yet used anywhere

All SPI-based device drivers needs to call SPI_HWFEATURES() with zero in order to co-exist with drivers that use H/W features

If there is no active connection (e.g. it is waiting in accept), then
the connection object, which doesn't yet exist, should not be cleaned
up when the socket is closed.

During a write, if there is no more buffer space for the user data,
return the amount that was written instead of waiting until there
is free space.  If nothing has been written yet, then block as before.

This solves a deadlock that occurs if the user data is too large to
fit in the available buffer:  the write thread will block before any
data is added to the write queue, leaving no possibility that more
buffers will free up when they are ACKed (since they have not yet been
sent).  The write thread will then block forever and hold all of the
buffers.

TCP uses two semaphores for buffers, one for the entire buffer pool,
and one for the number of allowed buffers for readahead.  To avoid
double taking a semaphore under heavy load, release the semaphore
after waiting before trying to acquire both again.

It is possible for a socket to have no connection, for example if a TCP
socket is waiting in accept.  This checks for this condition in case the
socket is closed from a different thread.

When a socket is closed, it should make sure that any pending write
data is sent before the FIN is sent.  It already would wait for all
sent data to be acked, however it would discard any pending write
data that had not been sent at least once.

This change adds a check for pending write data in addition to unacked
data.  However, to be able to actually send any new data, the send
callback must be left.  The callback should be freed later when the socket
is actually destroyed.

When a poll requesting POLLOUT happens, the poll should return
immediately if a write will not block.  This change adds that, as
opposed to the old behaviour of blocking until a timer from the
Ethernet driver eventually triggers the poll to complete.

This is only implemented for buffered TCP.  Unbuffered TCP should
behave as before.

If stdout is a socket (e.g. telnet), then the debug message will cause
more TCP data to be sent, which generates another message, and so on