[gdb/testsuite] Generate .debug_aranges in gdb.dlang/watch-loc.exp

[gdb/testsuite] Generate .debug_aranges in gdb.dlang/watch-loc.exp

Before commit 5ef670d81fd "[gdb/testsuite] Add dummy start and end CUs in
dwarf assembly" we had in exec outputs/gdb.dlang/watch-loc/watch-loc a D
compilation unit at offset 0xc7:
...
  Compilation Unit @ offset 0xc7:
   Length:        0x4c (32-bit)
   Version:       4
   Abbrev Offset: 0x64
   Pointer Size:  8
 <0><d2>: Abbrev Number: 2 (DW_TAG_compile_unit)
    <d3>   DW_AT_language    : 19       (D)
...
with a corresponding .debug_aranges entry:
...
Offset into .debug_info:  0xc7
  Pointer Size:             4
  Segment Size:             0

    Address    Length
    004004a7 0000000b
    00000000 00000000
...

After that commit we have a dummy CU at offset 0xc7 and the D compilation unit
at offset 0xd2:
...
  Compilation Unit @ offset 0xc7:
   Length:        0x7 (32-bit)
   Version:       4
   Abbrev Offset: 0x64
   Pointer Size:  8
  Compilation Unit @ offset 0xd2:
   Length:        0x4c (32-bit)
   Version:       4
   Abbrev Offset: 0x65
   Pointer Size:  8
 <0><dd>: Abbrev Number: 2 (DW_TAG_compile_unit)
    <de>   DW_AT_language    : 19       (D)
...
while the .debug_aranges entry still points to 0xc7.

The problem is that the test-case uses a hack (quoting from
commit 75f06e9dc59):
...
[ Note: this is a non-trivial test-case.  The file watch-loc-dw.S contains a
.debug_info section, but not an .debug_aranges section or any actual code.
The file watch-loc.c contains code and a .debug_aranges section, but no other
debug section.  So, the intent for the .debug_aranges section in watch-loc.c
is to refer to a compilation unit in the .debug_info section in
watch-loc-dw.S. ]
...
and adding the dummy CU caused that hack to stop working.

Fix this by moving the generation of .debug_aranges from watch-loc.c to
watch-loc.exp, such that we have:
...
  Offset into .debug_info:  0xd2
  Pointer Size:             4
  Segment Size:             0

    Address    Length
    004004a7 0000000b
    00000000 00000000
...

Tested on x86_64-linux.