Support for optional longer menu strings

[vzahradnik]

Currently, TcMenu allows to send the menu remotely. Usually on the embedded device, we are limited with strict constraints, like small display, etc. However, embedControl is not limited at all. Usually runs on large displays and we have more options.

I will likely bypass this limitation by having a custom app where I just use the menuItem tree and the strings will be stored in an app. However, I think it could be useful to have an optional menuItem name for the remote connections.

Current state:
Displ. Settings <- Embedded side with small display
Displ. Settings <- Remote end in embedControl

Suggested solution:
Displ. Settings <- Embedded side with small display
Display Settings <- Remote end in embedControl

Suggested solution:
MenuTree should contain the display name and optional extended display name. If the extended name is not set, TcMenu will fallback to the default display name.

This is just an idea and hence I created this as part of the discussion and not as a feature request.

[vzahradnik]

Implementing this on the embedded side also increases the memory footprint. This shouldn't be a problem for boards like ESP32 but we should take it into account.

[davetcc]

Agreed, I originally thought to embed these extra strings into the form XML as either English extended or other translation (I think there's even an issue for it), they are gzip compressed and end up at least 50% smaller, if not more for text and XML. The designer can already embed forms into the board, and they can be accessed by the API. We could implement the decoder in python and C# and then the support would be universal.

[davetcc]

And the good thing is, that the embedded board never needs to look at the compressed XML, and it is compressed upfront by code generator, so doesn't need any decoder support. On the desktop and mobile platforms, they all have gzip support available.