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.

Only check for matches that can be improvements.

Only test whether len is > match_maxlen when at least the first byte
matches, and use a pointer to curry in the current offset, saving an
add per compare.

This eliminates more unnecessary compares, speeding things up further.

(Thanks to user jibsen on hacker news for the original suggestion.)

Also, update index type to int16_t.

Eliminate some unnecessary comparisons by making the position in the
index signed, and treating any negative value as not found, not just
((uint16_t)-1). Also, decrease HEATSHRINK_MAX_WINDOW_BITS to 15, so
index values with the highest bit set can be used as working space
for index optimization on the fly (some day).

Use 'if length >= 3' instead of 'length > 2' for the break even point,
sinec it makes the intent clearer, and pull the comparison outside of
the inner loop.

Increase HEATSHRINK_MIN_LOOKAHEAD_BITS to 2, since -l 1 won't compress.
Also, eliminate the corresponding MAX #define, since it has to be <= the
window size anyway.

Use a separate *pt == *pt2 instead of pt[0] == pt2[0] for comparison of the
leading byte, which should allow for better branch prediction.

Eliminate 'needle_index' in the inner loop -- it's only aliasing 'end'.

Also, add comments about the indexing strategy.

This can save a significant amount of time in push_bits, particularly if -w is 8.

1. Instead of storing an offset to the previous matching byte in the
   index, store the next matching byte bigram. Since the compression
   doesn't break even unless at least 3 bytes match, any single-byte
   matches in the index should just be skipped.

   Since this eliminates these false positives in one pass, it also
   removes work that would otherwise be done during every walk of the
   index's offset chain - possibly several times. This greatly
   reduces the time spent in find_longest_match().

   EDIT: This prematurely discards information from the index,
   damaging the overall compression effectiveness. Some of the
   links being skipped are still necessary for other chains, so
   they cannot be eliminated this way. It's still possible dynamic
   programming can be used for this, but the strategy in this
   commit doesn't quite work.

2. Eliminate the test of the first byte, since indexing already
   incorporates this comparison ahead of time.

*comment on rebase*

Since heatshrink.c is just the command-line interface,
but heatshrink.h is constants common to the encoder and decoder,
rename it to heatshrink_common.h to avoid confusion.