Delete some code that is no longer being used, but did not get deleted
during merging because of cherry-picking / out of order integration of
several concurrent pull requests.

Closes #22.

Conflicts:
	heatshrink_encoder.c

Apparently, gcc only warns about [u]int16_t comparisons on platforms
where sizeof(int) == sizeof(int16_t).  Seems like integer type promotion
happens here, and gcc only warns when it changes the comparison result.

The maximum buffer length is 1<<16 (when window size is 15), in which case
end takes values >=0x8000, and start between 0 and 0x8000, inclusive.
Which means we really want to compare unsigned pos to signed start
(except when start is 0x8000), so comparing them as either int16_t or
uint16_t would be incorrect.

But the difference between end-1 and start is always strictly less than
1<<widow_size, which makes it positive when interpreted as int16_t.
The only other case in which the difference between pos and start may
reach a positive value on 16-bit platforms is when indexing is used, the
window size is 15 and the backlog is empty, making start 0x8000, and pos
gets the sentinel end-of-list value 0xFFFF from the index.  This case is
handled by changing the sentinel value to 0 when the backlog is not full.
(Updated, see below.)

Conflicts:
	heatshrink_encoder.c

EDIT:
   Since commit 7e818d55 eliminates the backlog full calculations by
initially filling the backlog with zeroes (i.e., the backlog is always
full), the special case sentinel value of 0 is no longer necessary.

Closes #19.

Closes #18.

Using a lookahead size equal to the window size could previously lead to
an infinite loop (discovered and fixed by @unixdj, thanks). There really
isn't any benefit to having a lookahead size that large, as it only
applies when the entire input stream is the same. In all other cases, it
makes the compression ratio worse.

Closes #20.

BUG: When window size equals lookahead, the encoder enters an endless
loop after WINDOW_SIZE bytes are sunk into the buffer, unless at EOF.

Test:
$ echo -n 0123456789abcdefX | ./heatshrink -w 4 -l 4 >/dev/null

Closes #21

Closes #21

As reported by @unixdj, there is a case where a few bytes can be
dropped from the end of the bytestream when used with a window_sz2
of 4 and lookahead_sz2 of 2 (-w 4 -l 2):

    $ echo -n aaaa | ./heatshrink -e -w4 -l2 | ./heatshrink -d -w4 -l2
    a   # should be "aaaa"

While st_check_for_input can treat 7 bits as sufficient input when
-w is 4 and -l is 2, that creates a corresponding issue where 1
spillover bit from the previous byte leads to filler of 0b000 0000,
which is interpreted as a marker to repeat (0b0) from 1 byte back
(0b0000) for 1 byte (0b00), leading to a duplication of the last
byte of input. Using a w,l pair where w+l < 7 leads to trailing
bits that are ambiguous, so raise the minimum lookahead bits to 3.

This problem does not occur with -w 4 -l 3, or any other valid config.

This is to ensure the full state space is explored. malloc (and re-use,
after zeroing) large in-memory buffers for use in the tests, as these
will not potentially fill the way smaller stack-allocated ones can.

Thanks to @unixdj for finding this bug and providing very detailed
info about how to reproduce it!

Minor change for C99 compliance for an old compiler. no behavior changes

Main changes:

1) Several portability improvements for Windows/MinGW and other platforms.
   Thanks Phil Pemberton, Steffen Jaeckel.

2) Significant improvement of the Makefile / build setup, to make
   switching between builds of heatshrink using static or dynamic
   allocation easier.

3) Added property-based tests (Optional; depends on theft) to the test
   suite.

i.e., libheatshrink_dynamic.a and libheatshrink_static.a, which use
dynamic allocation and static allocation (as configured), respectively.
Build both, both test suites, and the command line tool.

Get rid of the default "make" target that just suggested modifying the
config and building one or the other.

Add 'make install' and 'make ci' targets.

Fix implicit getopt

Fix a number of Windows-specific issues

All status messages should go out on stderr in case we're piping compressed data to other processes. Otherwise those errors might end up silently dumped into the data stream, and the error may go unnoticed.

On Windows, stdin and stdout are opened in text mode. We need to reopen them in binary mode in case users are piping compressed data around.

On Windows, binary files must be opened with the O_BINARY flag. On other platforms, O_BINARY isn't even defined. This resolves #9.

Port Steffen Jaeckel's fix from sjaeckel/heatshrink commit a98ba4612... to the latest Heatshrink source.

If the decompression stream was terminated with a 1 bit at exactly the
byte boundary (perhaps due to decompressing from flash memory and
sinking erased 0xFF bytes until the end of a flash page), it could end
up in a state where heatshrink_decoder_finish() would return
HSDR_FINISH_MORE, but calling heatshrink_decoder_poll would always yield
0 bytes of output. If _both_ results were not checked, this could lead to
the code driving them uselessly calling them in a loop.

Added regression test case:
decoder_should_not_get_stuck_with_finish_yielding_MORE_but_0_bytes_output_from_poll

Resolved by explicitly checking remaining input length in
heatshrink_decoder_finish in the HSDS_YIELD_LITERAL state, since it is
not safe to assume that the decompression stream input will be padded
with 0 bits.