X.{A.{{Grid,Tree}Select,Submap},Prompt}: KeyPress handling fixes

[liskin]

Description

This is a cleaned up version of https://github.com/xmonad/xmonad-contrib/pull/590 which additionally addresses https://github.com/xmonad/xmonad-contrib/issues/290 (I believe nobody really depends on the XKB and mouse state not being stripped so it's okay to change behaviour) and https://github.com/xmonad/xmonad/issues/172 (this needs https://github.com/xmonad/xmonad/pull/374).

Original description from https://github.com/xmonad/xmonad-contrib/pull/590 follows:

This changes makeXEventhandler to behave much closer to how xmonad itself handles keypresses. The primary difference lies in that xmonad reads raw keycode and then converts it to unmodified keysym, while makeXEventhandler was reading actual keysyms. As a consequence, key definitions like (shiftMap, xK_Tab) didn't work with makeXEventhandler on many layouts because an actual keysym for 'Shift+Tab' is commonly ISO_LEFT_TAB, and not Tab.

Additionally, the mask is stripped of its high bits, because apparently X likes to encode current layout group information in bits 13 and up, and we don't really want our control keys to depend on the current layout group. Please let me know if there is a better way to handle this.

One thing to consider: if we are concerned that unconditionally stripping XKB and mouse state might break someone's workflow, we'll need to make this configurable, and then we'll need to move cleanKeyMask out of X.Prelude as we can't import X.U.ExtensibleConf.

Checklist

• [X] I've read CONTRIBUTING.md

• [X] I've considered how to best test these changes (property, unit, manually, ...) and concluded: I manually tested TreeSelect and Prompt and haven't found any breakage.

• [X] I updated the CHANGES.md file

[liskin]

(merged without the stripModMask bit which has a separate PR now: https://github.com/xmonad/xmonad-contrib/pull/687)