Add a new config setting to change the keys used to select labels

[jirassimok]

(My other two PRs are minor and probably-uncontroversial bug fixes. This one is a significant enhancement that includes some design decisions.)

I find that it's easier to read capital letters at a glance when using tile mode, so I want my labels to show capital letters. But if I set mode_tile.label_symbols=ABCD..., I have to press shift to select a target.

This PR introduces a second, optional configuration option for tiling and floating modes, which I named keys. If it is empty, no behavior changes. If it is set, it must be the same length as label_symbols, and it represents the keys to listen for to select the corresponding symbols.

So if mode_tile.label_symbols=ABCDE and mode_tile.keys=abcde, the tile will display labels like AA BA CA, but will listen for regular, lowercase keyboard keys.

To achieve this result without interfering with UTF-8 symbols, I added a new field to label_symbols_t that represents the keys (and renamed .data to .symbols), and changed several of the label_symbol_* functions to refer explicitly to keys.

One potential issue here is that I did not name static methods as nicely as I could have; two of the new helpers for setting up label symbols don't start with label_symbol_.

---

I'm not sure looking at the individual commits will be very helpful to understand these changes more than looking at the total diff. Maybe dc14caf would be useful, though. That's my initial implementation, without as many renames to confuse the diff. But several of the later commits swap the meaning/effect of the options/fields, so it doesn't really look like the final version.

(Also, note that the first commit here is the commit from #63.)

[jirassimok]

Update: I added a second bugfix to #63, so I've rebased these changes onto that as well.

[jirassimok]

Rebased onto main again.

[moverest]

I see what you're trying to accomplish. Whilst I don't have a use for it, it's not a bad idea.

I think it would be easier to test and introduce less code if you were to just have two label_symbols_t structs in the bisect_state structure and use one for rendering and the other for the key matching. Just checking that there are the same size would do the trick.

[vdawg-git]

Wouldnt it make more sense to just introduce a "show_uppercase" option?
Because in what other cases would you want the display to deviate from the pressed keys?

[jirassimok]

Just going to uppercase does sound like a much easier idea, and I did consider it early on. I think I did it this way for two reasons. One is because the code accepts Unicode characters for the labels, and this way let me avoid having to figure out how multi-byte characters keys are handled here.

And depending on how the Unicode support works (and what international keyboards people use), I can imagine cases where you actually might want to choose a different character (like ß, which is traditionally capitalized as SS).

---

And re: @moverest, just having a second label_symbols_t does sound like a convenient way to implement this, but I got a job around when you suggested it, so I'm not sure when I'll have a day free to try implementing that.

[moverest]

No worries. I also happen to have started a new job recently which means I'm not spending a lot of time on the project at the moment either. I will spend more time eventually.