SML: FastExit for binary SML parsing

[rPraml]

Description:

This improves performance for the SML parser for type 's' (SML binary smart message coding)
We assume, that an SML message always starts with 0x77 / SML_SYNC and start decoding only, if the buffer starts with the sync byte.
If there is a rare case, that an SML message does not start with 0x77, this improvement can be disabled with flag 32

Details:

I noticed a high load (~170) and slow FPS on the connected display (240x240 ST7789)

With this PR I tried to improve the SML parsing for binary SML data, which seems to have some room for improvement.

As far as I understand the binary parsing, there is a buffer, where each byte is added at the end of the buffer and then the buffer is shifted one byte to the left.
After each byte, SML_Decode is called, which parses the the descriptor each time and checks if one line matches with the buffer.
(@gemu2015 is this correct?)

In my case I have 3 Logarex LK13BE606739 meters, where each transmits ~660 bytes each second.
My descriptor has ~ 60 lines, which means that SML_Decode is called ~2000 times/sec. and it will parse and check each line in the descriptor.

As far as I see, all SML messages in binary mode will start with 0x77, so I thought, it could be a good idea to implement a fast exit, and start decoding only, when the buffer starts with the sync byte, which makes the decoding a lot of faster.
(0x77 occurs 23 times in my test sample of 660 bytes)

To test the improvement, I bound this to flag 32, but I want to discuss, if this could be the default. (is 0x77 really a sync byte?)

This change reduces the load from 170 to 100 and gives some extra frames on the TFT

Roland

Related issue (if applicable): fixes #

Checklist:

• The pull request is done against the latest development branch
• Only relevant files were touched
• Only one feature/fix was added per PR and the code change compiles without warnings
• The code change is tested and works with Tasmota core ESP8266 V.2.7.6
• The code change is tested and works with Tasmota core ESP32 V.3.0.0
• I accept the CLA.

NOTE: The code change must pass CI tests. Your PR cannot be merged unless tests pass

[gemu2015]

that seems to be a good improvement.
i would suggest to make this the default und invert flag & 32 as i also assume that 0x77 is always present.

[rPraml]

I've modified the PR a bit. I still have to test this and provide a PR for documentation update...

[rPraml]

This PR is tested on an ESP32-S3 and works IMHO

[eku]

Wouldn't the code be easier to understand if a constant with a descriptive name were used for the numerical value 32? And since a bit is obviously being tested here, the use of 0x20 is a good idea.

[rPraml]

Is this the same comment as #21497 (review) ?
This is already fixed.