[defaults] Add transient state for winner-undo and winner-redo

[fnussbaum]

winner-undo is often used repeatedly, and winner-redo can only be invoked immediately after undoing. Hence SPC w u now enters a transient state, and the SPC w U binding is removed in favour of the transient state U binding.

[bcc32]

SPC w . is already a window-related transient state that has the undo/redo key bindings, it seems a little redundant to have SPC w u do something so similar.

[fnussbaum]

I think winner-undo is not very convenient to use without entering a transient state (or using repeat-mode), other than in special cases where one just wants to undo deleting a window. But in that case SPC w U is unnecessary. We could make SPC w u enter the existing window transient state, if that is preferable. However, personally, I never need any of the other window TS bindings after initiating a winner-undo sequence, and crucially, a lot of keys are bound in the window transient state that make exiting the transient state slightly less convenient. So the idea of having this additional tiny transient state is, that is is minimally invasive while adding convenience.

@bcc32 @smile13241324 What do you think? Leaving this in my own configuration and having to use SPC w . u by default would be fine for me too. (Although then the existing SPC w u and SPC w U bindings do not make much sense to me.) Otherwise I'll update the documentation as well.

(Similarly I have bound SPC b p, SPC b n and SPC b d to the corresponding buffer transient state commands in my configuration. In these cases I find the additional TS bindings very useful. But this is probably best left to user configurations.)

[bcc32]

I don't feel particularly strongly either way about what the right key bindings are, I mostly wanted to make sure you were aware that this other transient state existed and does something very similar. I would be fine with adding the original proposed change,

[smile13241324]

Jep the original change is fine with me