-var-list --locals proposal

[Vladimir Prus <ghost at cs dot msu dot su>]

As promised, I have a proposal how to improve local variables
display in MI. At the moment, varobjs for locals should be created
by frontend, presumably after getting the list of local via -stack-list-locals.

That's good, but the list of locals generally change when stepping though
the program:

1. When entering or leaving a function, the list of locals changes
completely.

2. When entering a nested scope, new locals appear. A variable in a 
nested scope may have the same name as a variable in an inner scope.

3. When leaving a nested scope, some locals disappears.

At the moment, to reliably show all locals, the frontend is forced to emit
-stack-list-locals on each step. To handle the case where a new variable
is in nested scope and has the same name as a variable in outer scope,
the frontend should compute addresses of all variables on each step,
and notice when they change. This is rather nasty.

I propose to introduce a new command:

	-var-list --locals <frame>

This command returns variable objects corresponding to every local
variable that is "live" at the current position in the program. If at all
possible, the command tries to return previously returned variable object.

So, on each step, the frontend emits -var-list --locals and:

	1. For all variable objects it never seen, create new GUI
	elements.
	2. For all variable objects that were reported previously,
	but are no longer reported, delete GUI elements.

The 'frame' parameter specifies whose frame's locals should be
returned. I envision that varobjs be reused across frames. So,
if you invoke:

	-var-list --locals 1
	-exec-finish
	-var-list --locals 0

the second -var-list will try to return the same varobjs that were
returned by the first -var-list.

The question is what exactly can be considered "live" variables by
-var-list. I think that to avoid creating and destroying variable
objects as we step though inner blocks, -var-list should construct
varobjs for all variables in all blocks of a function.

Then, at each point in the function each varobj can be in one
of three states:

	1. Accessible in the current scope.
	2. Accessible in some of the outer scopes (hidden
	variable).
	3. Not accessible (variable in a scope we've not
	entered).

Transition between those states can be reported via -var-update. The
differences between (1) and (3) is already reported via "in_scope" attribute.
I'm not sure if we need to expose the difference between (2) and (3),
and if so, if it's better to introduce another attribute -- "hidden" with
values "true" and "false", or new attribute "visibility", with values of:

	"yes"
	"hidden"
	"out_of_scope"

In any way, this is rather small detail that can be changed later.

Comments?

- Volodya