- 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

the inferior exited.
    Details:  that catches early exits due to startup problems as well

extra prompting

Conflicts:

	src/plugins/debugger/gdbengine.cpp

just treat it the same as internal apps as far as gdbengine is
concerned.

failed

    Details:  feels better

sometimes...

Conflicts:

	src/plugins/debugger/gdbengine.cpp

Conflicts:

	src/plugins/debugger/gdbengine.cpp

setting

initialization

watch view update

Conflicts:

	src/plugins/debugger/gdbengine.cpp

Conflicts:

	src/plugins/debugger/gdbengine.cpp

Conflicts:

	src/plugins/debugger/gdbengine.cpp

Conflicts:

	src/plugins/debugger/gdbengine.cpp

watch view update