Packet parsing rewrite - testing requested

[celsworth]

Note that the linked PR does not currently have database writing support, if you depend on that, hold off for now

Anyone following along at home may be aware of the recent discussions around finally fixing the packet parsing and limitations in lxp-bridge. It's starting to stifle a few feature requests and the addition of ReadInput4 has meant that with the current system it's really quite difficult to cope with all the permutations of inverters we now support. In particular, when to publish inputs/all was getting problematic, and there's been requests to publish updated registers on MQTT when they get changed externally, etc.

So this PR - #249 - attempts to address some of that. It's kind of a pre-dev testing phase :)

In short the old nom based packet parsing has been ripped out and replaced with homebrew parsing which allows us to be much more flexible - it doesn't depend on receiving exactly 0-39, 40-79, 80-119, or 0-127.

Now lxp-bridge can work with any combination of input/hold registers. In the past I just assumed that lxp inverters sent 0-39, then 40-79, then 80-119, as that's what mine did. Newer firmwares/inverters do different things. If in future an inverter turns out to publish 0-79 then 80-127 that's just fine, it will deal with that.

If you have an inverter that publishes the so-called 4 input packets, you need to update your configuration to have this at the toplevel (next to loglevel):

publish_inputs_all_trigger: 120

By default this is 80, which keeps existing behaviour from 0.13 and earlier (publish all after ReadInput3). If you set it to 120, then the inputs/all message will get published after lxp-bridge receives input register 120 instead (ie, ReadInput4). This is intentionally flexible enough to cope with yet even more registers in future, like going up beyond 127 or whatever.

Other notes:

• I've added individually published input messages with parsed values, which deprecate the inputs/1 (2,3,4) and inputs/all messages, though I've left them in for now. HA has been updated to monitor the new messages. If you use the older combined messages in your own code, please consider adapting to watch the new topics.
  • the topics are in the format lxp/BA12345678/input/v_bat/parsed - using the JSON key so you don't need to care about register number - with a parsed payload such as 50.2
  • existing raw input messages are unchanged, so the equivalent to above would be lxp/BA12345678/input/4 containing 502.
• database support is not yet in, and not sure if it will be, considering extracting this to external scripts because databases in Rust are just a pain and I think it's quite a minor feature
• one requested feature, publishing updated ac_charge times (and others) when they're changed externally, eg on the LXP interface, is now done and should be working. HA should see these changes accordingly.
• sorry no Docker builds atm, that will come after the PR is merged in.

Please report any issues!