Add keyboard labels symbols

[zacharie-moughanim]

This PR aims at naming symbols that are often used as keyboard labels.
This regroups within a submodule - as was suggested in this PR - symbols coming from across several unicode blocks : Arrows, Supplemental Arrows - B, Control Pictures, Miscellaneous Technical, Miscellaneous Symbols and Arrows, Miscellaneous Symbols and Pictographs.
There are probably some other I've missed, if you know some, I'll add them.
I've tried to add a large proportion of symbols that may be in the submodule in the end. Some I've considered and did not add, some I'm not convinced should stay but I put anyway to open the discussion. See this table to see all the symbols I considered.

Here are some remarks about the choices of names that I think needs to be discussed :

• Some arrows (↸/⭶, ⇲/⭸, ↹/⭾, ⇤/⭰, ...) both exists as simple arrows, and yet a very similar arrow exist with the main purpose of designating a keyboard label in the Unicode chart. I chose to put arrows resembling-but-whose-main-purpose-is-not-being-a-keyboard-label as alt. However this becomes weird for three tab symbols: ↹/⭾/⭿; the third one is a vertical tab, and is rotation of the second one, being itself an arrow but not primarily a keyboard label, while the actual designated symbol for keyboard is ↹ and has no vertical counterpart. For now, tab.alt.v is set to the ⭿, so tab.v falls back to it.
• I named four variants of capslock. Only one of them is not designated as capslock in the Unicode chart (⮸), but I put it for its resemblance, and the fact that it's a combination of variation on other symbols designated as capslock.
• I used the variant name struck for some capslock to designate a horizontal bar inside the stroked arrow e.g. ⇫/⇬ although it does not correspond to what is called struck for other arrows. I'm looking for a better name for this variant.
• There are 3 symbols designating a removal of inputs : ␥, ⌦, and ⌫, respectively named del, erase.r and erase.l. The first name is for consistence with the control pictures block (it's an alternate symbol for a symbol named del in the control submodule here), however there is also erase.l that I think is used to designate the same key (namely, the one deleting characters to the left of the cursor, so the naming feels weird here.
• The symbol for the option key ⌥ is also sometimes used for the alt key (description of the Unicode chart). There is another symbol for the alt key: ⎇ and I don't know if it's a good idea to put the first one a second time in the module as an alternate symbol for the alt name (Unrelated but alt.alt would be a bit weird and I have no idea what the name could be otherwise).
• Sometimes regrouped under "Keyboard symbols" on Unicode charts - along with symbols used as keyboard labels - are symbols representing a keyboard. I named them but I don't think they should be in this submodule (plus they are currently named keyboard.keyboard which, in my opinion, feels off like alt.alt).
• I didn't put any simple arrows that could stand for the arrows at the bottom right of the keyboard because I did not find a unicode symbol mentioning these keys. I'm curious if you have any idea what arrow to pick here, or if we should pick one at all.
• The arrow ↵ (from the Arrow block) is described as "may represent return or newline on keyboards" in the Unicode chart. Since there are other symbols for both these keys, I put it with both names return.alt and newline.alt.
• I had difficulty drawing the line between what should and should not be in this submodule. Among symbols I'm not sure should be here, and are in the submodule right now are symbols to adjust sound. Some I think should stay like speakers symbols (used for increase/mute/... the sound on a keyboard). Nonetheless, I feel like some, like fast-forward, are more MP3's or DVD player's button labels rather than keyboard's. Among those I did not put are lock 🔒 and bell 🔔. (All considered symbols, present or not in the submodule, are in the table linked at the beginning of this message).
• As was discussed in the PR about control pictures, I removed the spacebar for ␣ and moved this symbol in the submodule, whose full name is now keyboard.space. Plus, I think it should be noted that a similar symbol called SHOULDERED OPEN BOX ⍽ (the previous one is OPEN BOX) exists, although I did not name it here since I don't know if it's used as a keyboard label, tell me if it is used as such.

[Enivex]

I'm really not a fan of adding generic symbols with such specific names. Only symbols clearly intended to represent keyboard keys should be introduced this way.

[zacharie-moughanim]

You can see the table linked in the initial message to get all informations but quick recap :
Here are symbols not explicitly mentioned as key symbols :

• ⌂ HOUSE in Miscellaneous technical > Miscellaneous technical which, as said in the document, I don't know if it's actually used as a keyboard label, but other key symbols are used to denote "HOME KEY", I put it to open the discussion but I'm not convinced it should stay.
• ⌨ and derivatives which, even if it is in a group with key labels, represents a keyboard rather than being a key, so I don't think it belongs here.
• User interface symbols : none of U+23E9 - U+23FA should in my opinion be there and only a few among U+1F500-U+1F5AE, mainly speakers and brightness frequently used as keyboard labels although it is more generally a UI symbol for brightness and sound management.
• Power symbols U+23FB - U+23FE and U+2B58, same remark as for brightness and speakers.
• Lastly, there are generic arrows (from Arrows and Supplement-B Arrows blocks) described as key labels, but I'm not convinced whether to keep them or not. For instance : ⭰, see the initial message for a thorough explanation.

Feel free to tell me what you think, which among those (maybe all of them or more) you wish to see removed from this PR.

[MDLC01]

In general, I feel like a lot of symbols can be removed (for most of them, I left a comment asking for evidence of the symbols being used on actual contemporary people, i.e., being what users expect). Some can be added in a separate PR so that they can be discussed separately as a set.

To answer the various points you made in your OP:

1. Let's think when we have a smaller set of symbols to consider.
2. Addressed as a separate comment.
3. I agree that we should not use .struck for that.
4. Addressed as separate comments.
5. Let's keep a single name for each symbol, especially when the alternate name would be as an .alt of a different symbol.
6. I also agree they shouldn't be in this submodule.
7. I don't think there is a point giving hyper-specific semantic names to symbols that already have descriptive names in Codex. Also, various arrows fit this semantic, so let's let the end user choose the ones they want instead of having opinionated ones.
8. I don't like having different words for the same thing. I understand the problem: when multiple symbols have essentially the same semantic, there is a naming conflict. But I think the solution here is to simply choose one and give descriptive names to the others (in this case, ↵ currently does not have a semantic name but let's keep that for a separate PR adding more arrows¹).
9. Addressed as separate comments.
10. Addressed as a separate comment.

I did not go into a lot of details when reviewing this PR as I first want to reduce its scope to make it more manageable. Feel free to point out any oversight.

Footnotes

1. See also the huge Arrows section in the Symbol List for sym document. ↩

[MDLC01]

We are trying a new way to keep track of changes by maintaining the changelog in a separate shared document (https://typst.app/project/r2ChBGT9XWBoEhAKGM6icb). Feel free to drop the changelog update from this PR to prevent any further conflict.

[MDLC01]

There are still some review comments to address. I believe this is an exhaustive list:

• Add keyboard labels symbols #164 (comment)
• Add keyboard labels symbols #164 (comment)
• Add keyboard labels symbols #164 (comment)
• Add keyboard labels symbols #164 (comment)