Support Holley DTZ541 wrongly implemented CRC Algorithm

[hacki11]

I have a Holley DTZ541 where the CRC16 Algorithm is wrongly implemented by the manufacturer.
As already implemented in libsml volkszaehler/libsml#76 i did the workaround for opensml, too.

The meter often returns some invalid values which lets some calculations drift far away.
I'm using iobroker.smartmeter and hope this pr will be accepted and pulled upstream through https://github.com/Apollon77/smartmeter-obis and finally in https://github.com/Apollon77/ioBroker.smartmeter so i can enable the crc verification.
@Apollon77 ;)

added some test cases with holley sample data
feel free to review, iam happy to improve

[Apollon77]

Thank you, is there any way like via manufactorer string in the SML message to limit thjs special crc check to "just" the relevant sml messages?

[hacki11]

I see different issues

1. There are HLY DTZ541 with different firmware versions in the field. Since a specific version they fixed their issues. I do not know which version it is

2. I do not have direct access to manufacturer, product and version number in file or message parsing without major changes

3. there will only be an impact on malformed telegrams which crc is not valid. The users receive valid telegrams most of the time, if they receive a invalid message a additional crc is calculated. That won't affect performance and a crc hash collision for the invalid message becoming falsely valid is not very likely

If you have some suggestion I did not see feel free to give me a hint

[hacki11]

Is there anything else I can do?

[Apollon77]

I'm thinking about it atm :-)