See issue #119

i.e.:
Decimal: 4685616 (24Bit) Binary: 010001110111111100110000 Tri-State: F0F1F1110100 PulseLength: 146 microseconds Protocol: 1
Raw data: 4548,224,372,520,60,216,404,184,400,192,396,492,92,484,120,468,132,148,460,444,136,456,132,460,140,448,144,444,152,440,152,440,160,120,484,112,472,428,152,440,156,124,480,116,472,124,468,132,452,
Decimal: 4685571 (24Bit) Binary: 010001110111111100000011 Tri-State: F0F1F1110001 PulseLength: 149 microseconds Protocol: 1
Raw data: 4612,164,432,476,120,148,460,132,460,136,460,456,136,448,156,436,172,92,508,420,172,420,180,416,184,412,180,412,192,404,192,408,196,68,536,60,528,76,516,84,508,92,500,100,488,432,164,424,176,

Added transmit and receive support for devices using Holtek HT6P20X series encoders via a new protocol. See the datasheet for the waveform. This protocol uses pulses that start low instead of high requiring a few more changes than simply adding to the proto struct.

The old (and new again) semantics are that the bits in 'data' are sent
starting from the MSB. This had regressed recently to sending bits
starting at the LSB, as part of my refactoring.

Should resolve #52

Previously, for each bit we transmitted, we disabled the
receiver interrupt, sent the bit (as a high-low pulse), then
re-enabled the interrupt. For a 24bit tristate word, that
amounts to disabling and enabling the interrupt 48 times. Now
we only do it once.

Previously, sending worked by decoding a string which encoded
a binary or tristate codeword. Trying to send a bit pattern directly
(encoded as an integer) involved turning it into a string first.

This is a waste of memory and CPU cycles. So we do it the other way
around now: The central send() function accepts an integer containing
the bit pattern to be sent. The other send() function which takes
a 0-1-string, as well as sendTriState(), now call this new central
send() function. Incidentally, this reduces code duplication and enables
further refactoring.

This should fix #46

In particular, there is no need to #define CHANGE (it is not used
in the code if RaspberryPi is #defined), and don't override
PROGMEM and memcpy_P in the header; instead do that in the .c file,
to avoid polluting the global namespace

Since handleInterrupt always sets to changeCount a bit later, this does not
change program behaviour. It does, however, make it easier to understand the
code, and in particular, to verify that no overflow occurs here. See issue #44.

This commit mainly adds comments, and gets rid of one else-if, so it
should be easy to see that no functionality was changed so far.

It is now much simpler, results in a smaller binary, and is more
similar to the other getCodeWord methods

Also moved it to be before getCodeWordB, so the getCodeWord* methods
are now sorted alphabetically.

Overall, the RCSwitch code is a mess when it comes to uniform
formatting; but overall, it seems using 2 space indention is
predominant, so let's try to make sure new code uses that, and slowly
migrate existing code to use it.

Some compilers rightfully complain about this; it could also fool
somebody into thinking a string was returned, when in reality
that's not the case.

The new code is smaller and faster and perhaps also easier to understand

Test case:
https://gist.github.com/vgheo/f34ac7afd6447b3f1fc4

Fixed a dumb error (duplicate lines)

So far, while decoding the timings, the `handleInterrupt`routine only
iterated over protocols 1-3 before failing.

This small change will iterate over *all* protocols that have been
defined.

This resolves issue #32 (with a recent Globaltronics GT-FSI-07), and also is necessary
for compatibility with my Brennenstuhl RCS 2044.