Rebuild menus on keyboard change

Nobody has claimed this yet.

This issue is a spinoff of #1040.

Right now, menus tend to be set primarily on Window construction; there's a `set_menu` method available on a number of contexts (delegate, event, update, lifecycle), but it's up to the app when to call it. For simple apps, it's "fire and forget."

On keyboard change (WM_INPUTLANGCHANGE on Windows), the menus should be rebuilt so new vk codes for [ACCEL](https://docs.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-accel) can be computed from the semantically-meaningful hotkey descriptions (see also #1069 for more color about those mappings). If this were the only reason to rebuild menus, then what I'd suggest as an implementation strategy is that a semantically-meaningful representation of the hotkey map is maintained in the druid-shell platform implementation, then on keyboard change the new ACCEL is derived from this, invisibly to the app.

However, there are other good reasons to rebuild menus. In fact, I think ideally we *always* want to rebuild menus on a locale change, replacing the localized strings. Given that, I think having additional mechanism in druid-shell is somewhat wasteful. I suggest we have a mechanism for rebuilding menus on demand, and wire up keyboard changes to trigger that mechanism.

Start by inspecting the druid-shell platform implementation and the set_menu methods on the delegate, event, update, and lifecycle contexts. Trace how WM_INPUTLANGCHANGE is handled and how ACCEL values are derived. Done means menus can be rebuilt on demand, keyboard changes trigger that rebuild, and localized labels and accelerator codes reflect the new locale and keyboard.

Written by the indexing model from the issue text.