Completely re-work how we deal with mappings and macros: we now instantiate a new KateViKeyMapper and add it to a stack each time we expand a macro and pop it when we've expanded that macro. This way, we can still expand mappings in macros where the macro occurred due to the expansion of a mapping(!), but the whole thing is much less brittle (example of brittleness: pressing "capslock" in Insert Mode would crash(!), because the old method relied on m_doNotMapKeypressesCountDown, and KateViewInternal is structured in such a way that if a kepress is not handled by either of Vi mode or KateView itself - like capslock - it will be sent to Vi mode *twice*, which obviously interferes with m_doNotMapKeypressesCountDown. This is probably a bug in KateViewInternal itself, I suppose, but a generally harmless one).

I've removed the lengthy (and now obsolete) comment from KateViKeyMapper::handleKeypress(...).

This actually exposed a secondary bug where, if we played a macro while recording a macro (e.g. qb@aq), both the "@a" and the keypresses resulting from "@a" were both stored in macro b, leading to duplicated changes - I've fixed this via a m_isReplayingMacro flag (I did have an automated test for this, but it passed "by coincidence", as it were).