Change the UI to manage LCD screens to use individual output configs

[JaimeLeon2]

Is your feature request related to a problem? Please describe.
The current method to configure LCD screens requires the entire LCD screen contents to be in one output config. This requirement makes creating dynamic configurations (multiple formats) complicated when more than two variables change format. All data must be imported into the single output config as config references and all preconditions for the various possible states for all variables displayed must be considered as a whole along with their interactions.

Describe the solution you'd like
The enhancement I propose would replace the existing method of having the entire LCD in one output config with a new method where individual output configs refer to displaying to a position of the LCD screen. Very much like it is currently done for the 7-segment displays.

The new method would allow the user to individually create an output config and call any type of output value and assign it to display in a user-defined position in the LCD screen. At minimum, the user defines the format of the field, and its starting position. The LCD character positions can be sequentially numbered from 1 to 80 (for a 20x4 screen). For example:

COM1: ###.### Start pos: 21 (first column, second line)

"#" is of course a placeholder, which can be the same for all output configs writing to the LCD screen.

Because we would have individual control over each output config writing to the LCD screen (instead of one monolithic LCD screen buffer), the use of config references and preconditions is much simpler than the current method.

Following text is copied from the Discord #development channel

Let's assume we were able to configure each output config for one value and assign this to a position in the LCD display, Say Com1.

Config 1. You set your display field with
COM1: ###.### at start position 1.

Config 2. We create another config for Baro (inches):
Baro: ##.## starting position 21 (second line)

Config 3. Now using this as template we create two more configs
COM2: ###.### Start position 1 (same as before)

Config 4. and for Baro (HPa)
Baro: #### Start position 21 (same)

These are all individual output configs which will display in the same LCD screen position 1 and position 21.
Preconditions:
For config 1 , we set precondition Com Select =0
For Config 2, we set precondition Com Select=1
For Config 3, we set precondition Baro1 Mode = 0
For Config 4, we set precondition Baro1 Mode =1

That's it. This would display all four correctly in the two LCD display fields. No need for config references and only one precondition in each config.
To do this today, we need to create four LCD displays configs with two config references in each and two cascading preconditions in each LCD display config.
IMHO the current method is at least one level up in complexity from my idealistic example. The main reason for the added complexity being the requirement today that an entire LCD screen has to be one single output config

--- END OF DISCORD TEXT

Describe alternatives you've considered
Current method works, but is complicated when multiple variables are displayed with varying formats, requiring multiple LCD configs and multiple cascading preconditions.

Additional context
None

[DocMoebiuz]

Oh no! my long comment just got lost. So this time I will make it a bit shorter:

In general I believe the WYSIWIG approach of the LCD is better than the 7 segment style that you are proposing. Because for most people it is easier to place and align the values when they see how much space is left and what is already displayed on the display.

I also believe that most people are setting up entire pages. So for that use case it is also more straight forward.

You have a good "point" with the example of the decimal point (pun by accident). Baro and mach speed are the only two values that i can think of where you have a change from integer to decimal value. So as long as MobiFlight cannot deal with the decimal point, the decimal point requires an extra config.

I think I rather spend time on supporting decimal values than changing the config logic.

I will convert this issue into a discussion so that other people can chime in.