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)

When rolling a hotkey window in or out, do not animate it so that it begins or ends (respectively) on another screen. When screens have their own spaces windows can't span displays and the setting of the initial/final frame does something unexpected (like choosing a different frame in a completely different place). Issue 5871.

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

Fix a bug where non-animated hotkey windows did not follow the cursor from screen to screen. Issue 5786.

Change "Open in current space" for hotkey windows to move the hotkey window to the current space if it's already open on another space when the hotkey is pressed. Issue 5622.

Move hotkey window to screen with cursor when it's not animated. Mentioned in a comment in issue 3683.

Make it possible to save a hotkey window in a saved arrangement. Fix a bug where restored hotkey windows get an extra tab. I'm a little nervous about what this change might break, but I tested it and it plays nice with session restoration, default arrangements, and explicit saved arranagement restoration whether there's already a hotkey window or not. Issue 4924.

After a hotkey window rolls out we wait half a second for the previously active app to become active. This is because activating another app is slow. During that period you could not re-open the hotkey window. This commit introduces the idea of canceling a hotkey window rollout. It is cancelable after the animation and during the half-second window. When you cancel the rollout it becomes possible to roll in again. The other app will eventually become active so we wait half a second and if iTerm2 still isn't active and the window isn't rolling out then we make iTerm2 active again. Issue 5423.

- is hotkey window
- hotkey window profile
- reveal hotkey window
- hide hotkey window
- toggle hotkey window

The application now understands:
- create hotkey window with profile xxx

If a hotkey window does not yet exist, you must create it. If it does exist, it
can't be created again but you can change its visibility. Recommended usage is
to iterate over the app's "windows" properties and search for the hotkey window
you care about by asking each window if it "is hotkey window" and if its
"hotkey window profile" is the one you're looking for. If none is found, use
"create hotkey window with profile xxx". Otherwise, use "reveal hotkey window".

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.

Make the menu item to toggle whether a hotkey window is pinned modify the profile so it'll work when a window's profile specifies it is pinned

the screen that currently has the cursor. Issue 3374.

Revamps the logic for picking the screen to canonicalize the frame to.
Affects the screen used by fitWIndowToTabs. This probably has unintended
consequences but the code is more readable now and there should be fewer
cases where the window randomly moves to the main screen.

the screen that currently has the cursor.

Revamps the logic for picking the screen to canonicalize the frame to.
Affects the screen used by fitWIndowToTabs. This probably has unintended
consequences but the code is more readable now and there should be fewer
cases where the window randomly moves to the main screen.

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