DebugController: connect to Sublime::MainWindow::areaChanged once

DebugController::areaChanged is connected to
Sublime::MainWindow::areaChanged each time a debug session is started.
These multiple connections result in repeated calls to
m_currentSession->stopDebugger().

Usually the first stopDebugger() call clears the command queue, sets
s_shuttingDown debugger state on and queues a single command: GdbExit,
which is then immediately executed. In this scenario the additional
stopDebugger() calls have no effect, because they clear the already
empty command queue, notice that the s_shuttingDown debugger state is on
and return. However, if the current debug session was created by
attaching to a process with GDB, the first stopDebugger() call queues
two commands: TargetDetach and GdbExit. The TargetDetach command is
executed, but the GdbExit command remains pending. The next (redundant)
stopDebugger() call clears the command queue, that is removes/cancels
the pending GdbExit command, and returns. The gdb process does not exit
then. The fallback gdb-killing lambda, which runs after a 5-second
timeout, finds that s_programExited debugger state is on and does
nothing. As a result, the gdb process remains running, the debug session
and the MIAttachProcessJob remain alive. Starting another debugging asks
the user to abort the invisible currently running debug session. But the
session is not actually aborted because it is stuck with an unexpected
debugger state: s_programExited|s_attached|s_shuttingDown. In this way
it is possible to create an unlimited number of gdb processes, debug
sessions and MIAttachProcessJob objects, which are destroyed only on
KDevelop exit.