pdb was inconsistent in reporting changes to
breakpoints, reporting 'Deleted breakpoint #' in one
case, and not reporting the deletion in another.

This patch makes pdb consistently report
"Deleted/disabled/enabled breakpoint # at PATH:#"
for deleting, enabling, or disabling a breakpoint.

This makes it easier to integrate with IDEs such as
emacs gud mode (see discussion on python-dev startig
with
http://mail.python.org/pipermail/python-dev/2003-September/038147.html
).

Potential items for concern:

- I completely replaced the Bdb.get_break method.  It
was returning a boolean indicating if the breakpoint
existed or not, which appeared to be an error
(get_breaks returned the list of breakpoints).  The
method was never used in bdb.py or pdb.py, so I
replaced it with what I thought it should be.  :-) 
That is, it now returns the breakpoint instance
requested.  If there is a reason, I can easily make
this a new method
(get_breakpoint/get_breakpointinstance) rather than
replacing get_break.

- I've duplicated logic from Bdb.clear_bpbynumber into
a new method get_bpbynumber.  The logic differs only in
the return error messages or None.  This seemed the
simplest way to preserve the return value semantics
convention of the Bdb class.

- I'm also calling 'get', then 'clear' which does the
work of 'get' twice.  I did this to preserve the return
value conventions of Bdb and make the breakpoint info
available to the UI.  Shouldn't be a performance issue,
right?  ;-)

I believe this could go into 2.3.* and 2.4

Closing proposed, objections?

Why do you propose closing?

I had already realized[1] (thanks John!) I had no good reason to suggest
closing this one, bit forgot to update the issue, sorry.

I think it was a knee-jerk reaction to a RFE that was open for six years
without a 'ditto', but agree it's a valid request.

[1] http://mail.python.org/pipermail/python-dev/2009-February/086210.html

Thanks for the patch; I've committed a modified and extended version in r83275.