User map for characters in `lcd_gpio` and `lcd_pcf8574`

**Describe the problem you have/What new integration you would like**

There are different versions of Character-Based LCD Displays, for example the more commons driven by the HD44780UA00 chip English-Japanese or the HD44780UA02 English-European:
but there are even more, Chinese and Russian versions too.

The problem is that special characters above ASCII appear on various addresses in these screens. For example the `°` symbol is not in the same location. Using `°` in yaml config directly won't render it correctly, `\xdf` is needed for the English-Japanese model, and `\xb0` for the less common English-European.

Now to simply display `°C` you can't just use `return "\xdfC";` because `C` is a hex number, and the C standard does not define the maximum number of them in an `\x` escape sequence, so it is interpreted as part of it. To overcome this, you need to manually hack around with double-double quotes like `return "\xdf""C";` otherwise unexpected data appears on the screen.

The LCD screens (and the `lcd_pcf8574` / `lcd_gpio` components) also support adding a subset of `user_characters` which help with usage of diacritics in many languages.

The other problem is that using all these in strings is rather awkward, for example with the config below for `Hőmérséklet` we have to use `H\x09m\x05rs\x05klet`, but even worse, for `Főcím` we need to use `F\x09""c\x07m` (again need for a double-double quote).

**Proposed solution**

How about having a `user_map` configuration item where the user could cherry pick which characters/symbols have which hex address (based on tables above + the `user_characters`) based on the needs and from then, no more need to care about these in the rest of the config, replacements should be done automatically (maybe within `LCDDisplay::print`?), no need for escapes and manual taking care of the occurrence of potential hex characters following them:

```yaml
display:
- platform: lcd_pcf8574
user_map:
- °: "\xdf" # in the English-Japanese rom, \xb0 in English-European rom
- ^: "\x08" # in user_characters
- ó: "\x02" # in user_characters
- ö: "\xef" # in the English-Japanese rom, \xf6 in English-European rom
- ő: "\x09" # in user_characters
- ú: "\x04" # in user_characters
- ü: "\xf5" # in the English-Japanese rom, \xfc in English-European rom
- ű: "\x03" # in user_characters
- é: "\x05" # in user_characters
- á: "\x06" # in user_characters
- í: "\x07" # in user_characters
user_characters: # example below for Hungarian
- position: 0 # \x08
data: # back arrow
- 0b00100
- 0b01000
- 0b11110
- 0b01001
- 0b00101
- 0b00001
- 0b11110
- 0b00000
- position: 1 # \x09
data: # ő
- 0b00101
- 0b01010
- 0b01110
- 0b10001
- 0b10001
- 0b10001
- 0b01110
- 0b00000
- position: 2 # \x02
data: # ó
- 0b00010
- 0b00100
- 0b01110
- 0b10001
- 0b10001
- 0b10001
- 0b01110
- 0b00000
- position: 3 # \x03
data: # ű
- 0b00101
- 0b01010
- 0b10001
- 0b10001
- 0b10001
- 0b10011
- 0b01101
- 0b00000
- position: 4 # \x04
data: # ú
- 0b00010
- 0b00100
- 0b10001
- 0b10001
- 0b10001
- 0b10011
- 0b01101
- 0b00000
- position: 5 # \x05
data: # é
- 0b00010
- 0b00100
- 0b01110
- 0b10001
- 0b11111
- 0b10000
- 0b01110
- 0b00000
- position: 6 # \x06
data: # á
- 0b00010
- 0b00100
- 0b01110
- 0b00001
- 0b01111
- 0b10001
- 0b01111
- 0b00000
- position: 7 # \x07
data: # í
- 0b00010
- 0b00100
- 0b01100
- 0b00100
- 0b00100
- 0b00100
- 0b01110
- 0b00000
```
**Please describe your use case for this integration and alternatives you've tried:**
The new [LCD menu](https://github.com/esphome/esphome/pull/3406) component will likely raise the need to find a solution to these problems, as there the number of strings to be used will increase dramatically.

**Additional context**
https://github.com/esphome/esphome/discussions/3547#discussioncomment-2932369

Start by reading the lcd_gpio and lcd_pcf8574 components, especially the proposed LCDDisplay::print integration and existing user_characters configuration. The issue describes a user_map that would map symbols to display addresses and replace them automatically; done means configured characters render without manual hexadecimal escapes. No test file or implementation entry point is named.

Written by the indexing model from the issue text.