[gdb/breakpoints] Stabilize info breakpoints output

[gdb/breakpoints] Stabilize info breakpoints output

With test-case gdb.multi/pending-bp-del-inferior.exp, occasionally I run into:
...
(gdb) info breakpoints^M
Num     Type           Disp Enb Address    What^M
3       dprintf        keep y   <MULTIPLE> ^M
        printf "in foo"^M
3.1                         y   0x004004dc in foo at $c:21 inf 2^M
3.2                         y   0x004004dc in foo at $c:21 inf 1^M
(gdb) FAIL: $exp: bp_pending=false: info breakpoints before inferior removal
...

The FAIL happens because the test-case expects:
- breakpoint location 3.1 to be in inferior 1, and
- breakpoint location 3.2 to be in inferior 2
but it's the other way around.

I managed to reproduce this with a trigger patch in
compare_symbols from gdb/linespec.c:
...
   uia = (uintptr_t) a.symbol->symtab ()->compunit ()->objfile ()->pspace ();
   uib = (uintptr_t) b.symbol->symtab ()->compunit ()->objfile ()->pspace ();

-  if (uia < uib)
+  if (uia > uib)
     return true;
-  if (uia > uib)
+  if (uia < uib)
     return false;
...

The order enforced by compare_symbols shows up in the "info breakpoints"
output because breakpoint::add_location doesn't enforce an ordering for equal
addresses:
...
  auto ub = std::upper_bound (m_locations.begin (), m_locations.end (),
			      loc,
			      [] (const bp_location &left,
				  const bp_location &right)
				{ return left.address < right.address; });
   m_locations.insert (ub, loc);
...

Fix this by using new function bp_location_is_less_than
(forwarding to bp_location_ptr_is_less_than) in breakpoint::add_location.

Tested on x86_64-linux.

Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
PR gdb/32202
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32202