Typo fixes
Honor LDFLAGS
WIZARDISHUNGRY

Dynamically size terminal using SIGWINCH

https://github.com/antirez/dump1090/commit/f18180fef4ea6e0195d55439d93c4d717c35da8f
antirez

Constant replaced with macro MODES_NET_SERVICES_NUM.
antirez

modesFreeClient() optimized to find new maxfd faster
antirez

Free the client on best effort write(2) short write
BUGFIX : Missed data causes timestamp slip

The Mutex on the RTL data reader thread does not "force" the data
processing thread to execute. Therefore, if the processor is busy, it is
possible for a second RTL callback to occur before the data from the
first has been processed. This will cause the loss of the first data,
but worse, it will cause a slip in the timestamp. This upsets Beamfinder
and MLAT operation in PlanePlotter.

To solve this, keep a Fifo buffer which is filled by the callback
thread, and emptied by the data processing thread. The fifo is the same
size as the number of buffers requested in the call to
rtlsdr_read_async().

Note - we only put the value of the pointer supplied in the callback
into the fifo. We do not attempt to cache the data in the buffer pointed
to by the pointer.  This would require us to memcopy() 2Mbytes per
second, which we don't want to do if we don't have to because it will
only make the processor loading worse. Instead, we assume that the data
in the buffer will remain valid after the callback returns, at least
until it is overwritten by new data.

It is still possible for us to lose data if we can't process it quickly
enough. However, we can now detect this loss of data when the fifo is
almost full, and correct the timestamp for the lost block/blocks.
BUGFIX : Beast Binary Escape characters

Thanks to Blort on the PP list.

The Beast binary message stream uses the 0x1a character a and escape to
mark the beginning of a new message. However, the 0x1a character could
occur in the body of a message since the message is binary. Therefore,
the 0x1a is repeated  -as Blort put it :

This 56-bit Mode S Frame (containing a 1a) is supposed to look like
this:

1a  32 00 00 48 7b a6 1a 1a 0c  20 28 17 b0 c0 c3 b0

What is actually looks (looked) like (from wireshark) is this:

1a  32 00 00 48 7b a6 1a 0c  20 28 17 b0 c0 c3 b0

There are supposed to be two 1A’s (Gunter’s Escape Character) in a row
(1A 1A) whenever a data byte contains 1A, after the initial two 1A 3x
characters.
Publish V1.08.2302.14

Final tidy up and publish