New 'lf hitag pwmdemod' cmd decoding the reader messages from graph b…

[codeflakes0]

This new command is based on the 'data rawdemode' commands.
It is intended to be used on graph buffer data captured with a previous 'lf search'
Since the decode is done in variable bit range I've had to modify proxguiqt.cpp to take into account. Not sure
if this was the best way to deal with this problem.
There is a know bug when zooming and scrolling, the displayed demodulation bits are shifted and do not follow the signal.

[iceman1001]

hm.. interesting..
maybe it should have been under data pwm and not under hitag.
Not sure about the graph buffer doing.
the normal way is to copy it to your local array, put all demods into the demod array...
and thats it.

[codeflakes0]

Yes I though of adding the feature to the data cmd too as it's a very generic command. You decide.
The graph buffer I added was necessary because with this type of decode the period is not constant so the demodulation was not displaying correctly of top of the signal. It was progressively pushed too far on the right. But it is entirely possible this was not necessary and I just did not understand the graph code enough.

[github-actions]

You are welcome to add an entry to the CHANGELOG.md as well

[chrisfu]

Would this work as a int32_t? As it currently stands, builds are failing under the Darwin compiler due to period being unsigned.

[mwalker33]

What happens if "period" and "last_wave_start" are made size_t (to match idx) rather then uint32_t ?
i.e. is size_t the same size as uint32_t ? (on some systems I believe size_t is 8 bytes, which would make it 64 bits, twice the size of a unit32_t.