Open a new tab active, and in the background with Shift

Clicking a place or a breadcrumb with the middle mouse button, or with Ctrl held down, opened a tab in the background, and adding Shift activated it. A new tab is now the active one, and Shift is what asks for a tab in the background. The "Open in New Tab" entry of both context menus follows the same rule, where KFilePlacesView always asked for a background tab.

Which signal is emitted takes into account what the application listens to. One that connects only tabRequested, an open dialog for instance, keeps receiving that signal for every one of these gestures, so nothing changes for it.

In KUrlNavigator, the condition for an active tab tested the left button together with either Ctrl or Shift. A Shift+left-click was therefore taken for a tab request, and the branch below it could never be reached. Shift+left-click now opens a new window, which is what the description of these gestures in that function has always said it does.

Nothing told the user about the Shift key, so the "Open in New Tab" entry of both menus now carries a tooltip saying what it does, and its text becomes "Open in New Background Tab" while Shift is held down. A small private class shared by the two menus does this. An application decides whether menu entries show their tooltip at all, and KXmlGui offers KToolTipHelper for that.

Dolphin does the same for its own context menu and for a middle click in the view, in a separate merge request system/dolphin!1392. Neither merge request needs the other to land first.