Details:  Mac gdb produces MI-style output for the non-MI-style command

auto-dereferencing contents

Task:     246286

This reverts commit dcb43b04.

This reverts commit b99f3b61.

Details:  accounted for >60% startup time in some cases and was
presumably only needed as help for a fallback when setting breakpoints
with gdb 6.5 on Windows

rely on the inferior's pid being available. consequently, remove the
bizarre findChild stuff.

fixes interrupting processes with some versions of gdb

Details:  That works with a core file, too. The "real" dumpers require a
live process as they use gdb's "call"

includes complete refactoring of ConsoleProcess.

- remove stale connect()
- clear buffer after it was completely used

fixes chopping up of very long responses which quickly follow other
responses.

the line segmentation is done in readGdbStandardOutput() now.
handleResponse() is not called through a queued slot any more, as the
output receiver is already synchronized to the event loop.

it's broken and nobody seems to have noticed. that might be because the
interpreter doesn't care whether something is a list or a tuple.
if this is reintroduced for some reason, it should be done directly in
the affected code path.

setting the initial breakpoint at the entry point wreaks havoc, so set
it at main() instead. this will miss any breakpoints in global ctors and
(currently) makes it impossible to set an actual breakpoint at main.

unlike the upstream gdb, the mac one gives an MI response to "info
target" when in MI mode.

instead of picking "random" known entry point symbols, ask the debugger
for the actual entry point.
this also removes the "one instruction after the first one" hack, as it
seems fairly pointless.
NOTE: this does *not* work with the 2005 version of apple gdb.

Conflicts:

	src/plugins/debugger/gdbengine.cpp

Conflicts:

	src/plugins/debugger/gdbengine.cpp

also, make it complain upon abuse of this call.

Conflicts:

	src/plugins/debugger/gdbengine.cpp

instead of picking "random" known entry point symbols, ask the debugger
for the actual entry point.
this also removes the "one instruction after the first one" hack, as it
seems fairly pointless.
NOTE: this does *not* work with the 2005 version of apple gdb.

RevBy: ossi

also, make it complain upon abuse of this call.