Fix a bug where hotkey windows appearing in a different display than the currently key window (in another app) would not receive focus and would forget which app was previously active. Issue 6353

The two key changes are
1. Add a method to activate the app with a completion block
2. Don't throw away the existing previous state when a non hotkey window becomes key during a rollin. The logic already existed for a rollout.
Here's what would happen:

rollInAnimated
  [NSApp activateIgnoringOtherApps:YES]
  rollInAnimatingInDirection:
(if there's no animation, the rollin finishes immediately)
App becomes active
A non-hotkey window becomes key

Now, here's what happens:

rollInAnimated
  [NSApp activateIgnoringOtherApps:YES]
App becomes active
A non-hotkey window becomes key, but it's ignored because there's a roll-in in progress
rollInAnimatingInDirection:
(if there's no animation, the rollin finishes immediately)

Show a warning if the shortcut to toggle the app is the same as the shortcut to toggle a profile window.

Also fix a bug where duplicate warnings wouldn't be shown if some irrelevant modifier flag bits were set.

Issue 5882

Keep another app from becoming active after local auth dialog from pw manager sheet attached to hotkey window is dismissed.

Fix a hang when hiding a hotkey window that has sheets (was using deprecated API)

Issue 5860

0. Starting in another app...
1. Press a hotkey
2. Press a different hotkey, hiding the first window and revealing a second one
3. Press the second hotkey again, hiding the second window

there was a bug where you were not returned to the previously active app. This commit fixes that bug. Issue 5427.

Fix a bug where a non-hotkey window would briefly appear when hiding a hotkey and activating another app because we ordered out the invisible hotkey window before activating the other app. The OS ordered front a non-hotkey window just before the other app was activated. Fixing this (which means making the order-out happen after the app switch) had a bunch of knock on effects when there were multiple windows with the same hotkey, which this commit attempts to address by batching up changes to multiple hotkey windows and making the showing and hiding of "siblings" (windows with the same hotkey) more explicit. Brought up in a comment in issue 5313.

Fix a bug where the previously active app was not restored after pressing a hotkey that hides two different hotkey windows. The previous state with a previously active app got overwritten by one that did not have a previously active app.

There's some history here.

In issue 3199, a problem was revealed where when using a pinned all-spaces open hotkey
window and you switch spaces. Another app becomes active (which the OS is
fond of doing when you switch spaces). Pressing the hotkey hides the window
instead of revealing it. I put in a fix to reactivate iTerm2 and make the
hotkey window key and ordered front on a space change.

The 3.1 hotkey window changes made this less aggressive by just doing
orderFrontRegardless on the window.

But it still doesn't make sense because pinned hotkey windows should be
allowed to order back. Why should they jump on top when you switch spaces?
It would be nice if the window was key for it to remain so but I can't
effectively detect that (the resign active notification comes after the
active space did change notification, sometimes with a significant delay,
so they can't be correlated).

This changes backs out the fixes to those bugs and lets the OS manage the
window order and key app when changing spaces.

I believe the original problem in issue 3199 has been fixed: a pinned
hotkey window that is not key does become ordered front, not hidden, when
the hotkey is pressed.

window. This seems to respect the platform more than hijacking focus. Issue
5217.

Merge in code from hotkeyWindowsInPanels branch. Support multiple hotkey windows. Update the shortcut input view. Add support for floating panel terminal windows.