Added changes to release notes for version 0.99.0 due to nushell/#14020

[JustForFun88]

This PR includes details about Unicode code points in keybindings, as requested in the comment. The changes are based on the improvements introduced in #14020.

[sholderbach]

This attempt at explaining reasoning makes me even less convinced that this feature should be there.

The example of the ; is a bad explanation because it dances around the point the only limitation before was a poor understanding of the core tenants of nushells string syntax.
That we accept strings without quotes in our record syntax is a courtesy we provide (and an attempt to transfer the logic for (external) command calls) and depends on being free of otherwise confusable characters, you can't include : or , in a record bare string either. If our default config would use strings with quoting for the keycode entries it wouldn't have come up.
We should strive towards making it easier for our users to grasp more of the transferrable base concepts of Nushell they can apply in many other situations than adding more things you have to understand to paper over things that were unclear before.

Saying that you get a benefit in the capitalization is also questionable, the capitalization of non-ASCII alphabetic characters already mattered as well as the capitalization of the ASCII alphabetics without modifiers (CTRL, ALT etc.).
Passing a specific capitalization for the ASCII alphabetics with added modifiers (even through their codepoint id) still doesn't matter because reedline will coerce the ASCII capitalization for the keys with modifier. For all intents and purposes, that we coerce here doesn't really matter if users follow the output of keybindings listen in setting up their keybindings. It shows which modifiers will be active and the resulting binding will work. (we could clarify the behavior when improving our documentation there, but being lax there doesn't have much harm if you want to enforce some binding with specific modifiers anyways.)

Adding things to our documentation that can be misunderstood or are a product of misunderstanding doesn't help. I would rather not have those two sentences.

[JustForFun88]

Thank you for your feedback. I can remove the two sentences as you've suggested. However, would it be acceptable to mention that the new ability to specify Unicode code points in keycodes can be useful for eliminating confusion in configurations where characters from different Unicode blocks look identical but have different code points? For example, several Cyrillic letters appear identical to Latin letters (cyrillic symbols: а, е, о, р, с, у, х, А, В, Е, К, М, Н, О, Р, С, Т, У, Х), but they have different Unicode values. By specifying the Unicode code points directly, users can accurately define keybindings for these characters without ambiguity.

Would including this explanation be appropriate, or would you prefer that I omit this as well?

[sholderbach]

Yeah the character confusables sounds like the best motivation for using this feature to me.

[fdncred]

Definitely give an example of specifying Unicode code points. I agree that it's a key value prop here.

[JustForFun88]

Done

[sholderbach]

Awesome thanks!