gdb/testsuite: fix occasional failure in gdb.base/clear_non_user_bp.exp

gdb/testsuite: fix occasional failure in gdb.base/clear_non_user_bp.exp

I noticed that the gdb.base/clear_non_user_bp.exp test would sometimes
fail when run from a particular directory.

The test tries to find the number of the first internal breakpoint
using this proc:

  proc get_first_maint_bp_num { } {
      gdb_test_multiple "maint info break" "find first internal bp num" {
  	-re -wrap "(-\[0-9\]).*" {
  	    return $expect_out(1,string)
  	}
      }
      return ""
  }

The problem is, at the time we issue 'maint info break' there are both
internal breakpoint and non-internal (user created) breakpoints in
place.  The user created breakpoints include the path to the source
file.

Sometimes, I'll be working from a directory that includes a number,
like '/tmp/blah-1/gdb/etc', in which case the pattern above actually
matches the '-1' from 'blah-1'.  In this case there's no significant
problem as it turns out that -1 is the number of the first internal
breakpoint.

Sometimes my directory name might be '/tmp/blah-4/gdb/etc', in which
case the above pattern patches '-4' from 'blah-4'.  It turns out this
is also not a problem -- the test doesn't actually need the first
internal breakpoint number, it just needs the number of any internal
breakpoint.

But sometimes my directory name might be '/tmp/blah-0/gdb/etc', in
which case the pattern above matches '-0' from 'blah-0', and in this
case the test fails - there is no internal breakpoint '-0'.

Fix this by spotting that the internal breakpoint numbers always
occurs after a '\r\n', and that they never start with a 0.  Our
pattern becomes:

  	-re -wrap "\r\n(-\[1-9\]\[0-9\]*).*" {
  	    return $expect_out(1,string)
  	}

After this I'm no longer seeing any failures.

Reviewed-By: Tom Tromey <tom@tromey.com>