Fix access key for Replace in Edit menu

[dan-jac]

Currently, there's a conflict of access keys in the Edit menu – both Redo and Replace are assigned to R. This means that the Replace feature can't be accessed by Alt followed by a letter.

With this one-character bugfix, I've changed Replace's access key to L, which doesn't conflict with any of the other items in this menu.

This matches the access key used in old-school MS-DOS Edit.

Closes #56

[lhecker]

I'm somewhat hesitant to merge this due to this: #56 (comment)
What do you think?

[dan-jac]

I'm somewhat hesitant to merge this due to this: #56 (comment) What do you think?

I think it's great if an access key system is resilient enough to be able to support conflicts. (The old underline-based system in win32 supported this; the modern WinUI access keys are not resilient in this way.)

However, it's not ideal to have conflicts; ideally each item should have a distinct key to facilitate faster navigation.

Unlike with keyboard accelerators (Ctrl+[VK]) keyboard shortcuts, access keys don't usually have 'standard' mappings, and are usually assigned depending on context. Thus, I don't think there's a need to artificially make this access key match another app's choices.

tl;dr: I do think we should merge this.

Edit to add: I'm actually not convinced this app needs to be resilient to access key conflicts. The major value of supporting conflicts is to allow for the access keys to get localized, and to still work if the localization process fails to make each one unique within a given scope. But in this app, the access keys are not localized (and are not localizable). Given that this is a text-based app, this is probably fine. (Localizing access keys is a messy process.) So we have the luxury of being able to hand-assign access keys, ensuring against conflicts.

[lhecker]

After discussing this with @DHowett we agreed to merge this. Thank you for doing this!