Add samples and decoder for Geevon TX16-3 weather station transmitter

[FalconFour]

Fairly useful discovery - a $12 weather sensor on Amazon. Spent a weekend reverse engineering it and writing a decoder, but not sure if it snaps into place. Would love to see it polished and added!

[mrjones-plip]

@FalconFour - this is really awesome work! While I know it's not merged upstream yet, are there DIY steps to compile off your branch for those of us interested in using the TX16's? I'd like to use it with this project which currently uses a stock rtl_433 binary at the command line to pipe it into a script to post process (and POST to a remote server).

[zuckschwerdt]

This totally slipped by. Should be transfered and merged into the main repo. I'll see if I can get around to that soon.

[FalconFour]

A couple things to note. First, I've been using this decoder near-constantly with Home Assistant on my custom compiled binary on Mac and Windows alike - for the past year and change. It works pretty reliably and is extremely unusual (once every few weeks) to get a mis-read among untold thousands of reads, from 3 transmitters each on its own channel. However, I never put any further effort into error-checking, and frankly I may have messed up something along the way as it was more a "make it work, get it over with" (I don't have much fun working with code, it's more of a means-to-an-end).

Moreso, I wasn't quite sure what path to put this contribution into, so I hope it doesn't die here in the wrong workflow (as "tests" and not in rtl_433 proper). Just though it's better to have it here than die on my hard drive as forever a custom binary 😅

That said, I completely forgot about how I built it :( I think I had to add the protocol code file to the stack of protocol files, and then add it to a couple of definition files. That might not help much, and I'm sorry! But I remember it was a bit of a search to find the locations that call-in the existing protocol files, and then another one to add it to a list of protocols it "supports".

[mrjones-plip]

Thanks for the info @FalconFour ! I think the main work for this is now in the main repo pull request. I've asked how to reproduce the build with your code as well so we can both learn!

[zuckschwerdt]

@FalconFour I'm going to merge your code as-is now. If you got the time please check and confirm the battery_low bit.
The comment says Battery status (0 = good, 1 = low battery) and the example matches.
But the code had this condition inverted which I changed, but that might be incorrect?