Should StatusBar always win and capture any defined hotkeys?

[tig]

See #1256.

Proposed fix to TopLevel.cs:

public override bool ProcessKey (KeyEvent keyEvent)
		{
			if (StatusBar != null && StatusBar.ProcessHotKey (keyEvent)
				|| SuperView != null && ((Toplevel)SuperView).StatusBar != null
				&& ((Toplevel)SuperView).StatusBar.ProcessHotKey (keyEvent)) {
				return true;
			}

By doing this `StatusBar` will prevent any other `View` from receiving `ProcessKey` notifications for ANY hotkey defined for the StatusBar. For example:

```c#
			var statusBar = new StatusBar (new StatusItem [] {
				new StatusItem(Key.CtrlMask | Key.Q, "~^Q~ Quit", () => Quit()),
				new StatusItem(Key.Enter, "~ENTER~ Message", () => MessageBox.Query ("Message", $"ENTER")),
                                new StatusItem(Key.Enter, "~a~ Message", () => MessageBox.Query ("Message", $"a")),
			});

With this nothing else in the app will ever see 'ENTER' or 'a' keypresses.

My opinion is that this is probably fine. But I haven't considered all of the implications.

[BDisp]

In my opinion if the current focused view has a ProcessHotKey defined, then it must run first.
The order of the Application.ProcessKeyEvent is the following:
ProcessHotKey
ProcessKey
ProcessColdKey

So, due to this I think this not make sense, since the ProcessHotKey runs first than ProcessKey event.

[tig]

Closing as a dupe of #3042