Ivan:
-----

Some I was thinking of adding to the stack view were:

Expose/Hide hidden frames.
Dbx will sometimes replace a collection of frames with a  fake "hidden"
frame. These are usually part of the runtime like C++ exception hooks and
callbacks of runtime-checking instrumentation.
This can be genralized to the notion of filters I suppose. But then we'll
get into the problem of whether the GUI (debuggercore) is doing the
filtering, or the engine.

Control quick vs verbose stack views.
Dxb can show a quick stack view w/o reading too much symbolic
information. In a verbose stack back-trace you will get parameter values.
But if the verbose is turned on then two things will happen:
- more symbolic onformation has to be read for each new frame. 
  this takes time and makes the stack appear after a bit of delay.
- this symbolic information stays and adds to the VM footprint.
  So we usually recommend that users run with a quick stack frame.
  and turn verbose mode on if needed.
  
Dbx doesn't show all stack frames and has a limit.
This is to prevent io and gui swamping when looking at infinite-recursion
stack-overflowed stacks where you can have thousands of frames.  
In the gui I was thinking of adding a "more frames" fake frame at the
end of the stack trace. But how to reset that? An action in the view
so show less frames or reset the frame limit to a default makes sense. 


There are other reasons for being able to customize _existing_ view
actions.

One issue I posted a while ago that went unanswered had to do with
EnableAll/DisableAll going through the debuggercore Breakpoint.Event.set()
mechanism while I need to avoid that. I had asked for and gotten
my own enabled property in order to avoid B.E.set() 
but EnableAll/DisableAll still go that way.