LCD: refactor MKS H43 display code and UI

[narno2202]

Description

For my personal use, I have refactored the MKS H43 code and I am submitting this PR.

Summary of changes :

1. Fix compiler warnings
2. Fix some bugs related to typos.
3. Comment variables absent from MKS H43 firmwares (1.30, 1.31)
4. Improve UI wording : text more consistent with the supposed function (for example "Steps/mm" instead of "MotorPluse")
5. Change variable names accordingly

Requirements

MKS H43 display

Benefits

More consistency in the UI, bug fix

Configurations

Related Issues

[narno2202]

Some screenshots :

Before	After

Before	After 1	After 2

[thinkyhead]

Looking pretty good, but there were a variety of actual bugs. I'll merge all the cosmetic changes separately so the more relevant changes will be more obvious here … for posterity.

[thinkyhead]

Strings in Arduino can sometimes be tricky to understand and we haven't propagated consistent string usage to all parts of the code yet, sorry about that.

FTOP(F("String")) can be replaced with PSTR("String") … but it is preferable to use F() as arguments because a PSTR cannot be differentiated from a const char *. Polymorphic methods taking FSTR_P should have plain names like sendInfoScreen, but methods that require (or expect) PSTR_P should be named with a _P suffix to clearly indicate that all the const char * (PSTR) arguments refer to Flash and not RAM, e.g., sendInfoScreen_P.

Speaking of sendInfoScreen, the method declarations are all outdated. They take flags to indicate whether a given string argument is in RAM or Flash. Since our use of __FlashStringHelper makes it possible to detect F() strings at compile time we can now do proper polymorphism. Then we can add methods to handle special cases where F() and PSTR() strings are meant to be mixed with C-strings.

[thinkyhead]

As with the FTOP(F()) redundancy, FTOP(GET_TEXT_F(MSG_HALTED)) should be GET_TEXT(MSG_HALTED) to get the PSTR form of the named string.