Introducing MI branch

For recent months, I was working on an internal reorganization of KDevelop debugger, informally known as "MI branch". Now that it mostly works, it's time to describe the goals and results.

The original goal was to use a different interface with GDB, called "MI", that's specifically meant for frontends. In MI mode, gdb output can be easily parsed into DOM-like structure, and examined in a nice C++ way, something like:

(*last_stop_result)["value"]["old"].literal()

Before, KDevelop was parsing GDB output intended for humans, and could in some cases misinterpret it. Like thinking that application is running, when it's actually stopped. This unreliability was the primary reason for switching to MI.

But MI is not a silver bullet. Both John Birch (original author of debugger part), and I had reservation about maturity of MI, which proved true eventually. I'll talk about this later, but basically, using MI does not automatically make debugger better, or faster, or anything, contrary to what many think. However, since using different protocol is a big code change already, I've sneaked in a number of architectural and GUI changes, hopefully for better.

So in the end MI branch had two goals:

1. Fix all glitches. Do you know that in some cases KDevelop 3.3 shows only half of local variables? Or that setting watchpoint in a natural way is rarely what you want? Or that if a program is stuck in infinite recursion, KDevelop will take minutes to show the stack? Each issue is not very significant in itself, but together they make user experience not confortable.
2. Cleanup internal architecture. Original architecture was a bit too centralized and adding new features required a lot of work. And since many cool features come to mind, it's better be fixed quick.

The "MI branch" itself is already merged to KDevelop 3.4 branch. In future posts I'll describe all changes the debugger has compared to 3.3 release. Stay tuned.