MI: "^running" issues

[Vladimir Prus <ghost@cs.msu.su>]

I've just run into a somewhat nasty behaviour of gdb.
Suppose if you've set 5 hardware watchpoints (on x86)
and to -exec-step. The output from gdb will be:
	
	(gdb) -exec-next
	^running
	(gdb)
	34^error,msg="...."

The target is not really running at this point, but not that there's no *stopped
message.  This is because the "^running" is in error -- it's actually output
when we only start processing -exec-next.

I also recall the long-standing bug that "^running" is not output for CLI
commands. 

I really wonder if this is hard to fix? Can we just move the printing of "^running" to
target_resume, to catch all cases? Alternatively, we can notice that "^running" has
double duty if identifying that:

	- async operation has started
	- target has started

We can make "^running" more focuses by either:

	- Introducing "*running" notification, that means the target is running.
	- Making "^running" mean that the target has started. As for async/sync
	commands, gdb prompt will indicate new command will be accepted.
	- Killing the idea of async commands. It does not seem to be very useful
	at this point, so we might be better off ripping it and implementing afresh
	later, when it's understood what they should be.

Thoughts?

- Volodya