Gnu digit directive tests confusion

It's about:
```
clang/test/Preprocessor/line-directive-system-headers.c
clang/test/Preprocessor/line-directive.c
```
The tests pass, but I suppose just because of `#line` collisions

So, let look at the piece of `line-directive-system-headers.c`
```
1 // RUN: %clang_cc1 -fsyntax-only -pedantic -verify %s
2 // RUN: %clang_cc1 -fsyntax-only -pedantic -verify=system -Wsystem-headers %s
...
24 # 42 "foo" 3 4 // #7
25 // expected-warning@#7 {{this style of line directive is a GNU extension}}
26 // system-warning@#7 {{this style of line directive is a GNU extension}}
27
28
29 // Verify that linemarker diddling of the system header flag works.
30
31 # 192 "glomp.h" // #8: not a system header.
32 // expected-warning@#8 {{this style of line directive is a GNU extension}}
33 // system-warning@#8 {{this style of line directive is a GNU extension}}
34
35 # 192 "glomp.h" 3 // #9: System header.
36 // Warnings silenced when -Wsystem-headers isn't passed.
37 // system-warning@#9 {{this style of line directive is a GNU extension}
```
The test expects `// expected-warning@#8 {{this style of line directive is a GNU extension}}` to be emitted on `31 # 192 "glomp.h" // #8: not a system header.`, but if we run the test without `-verify`, we will see:
```
glomp.h:195:7: warning: this style of line directive is a GNU extension [-Wgnu-line-marker]
195 | # 192 "glomp.h" 3 // #9: System header.
```

I suppose `verify` cannot distinguish ` 31 # 192 "glomp.h" // #8: not a system header.` `35 # 192 "glomp.h" 3 // #9: System header.` because the same `#` locations are used.

If we change one `192` to another number the test stop passing

There are a couple of such errors in the tests above.

I'm not sure what compiler behavior is expected in the tests, but clang seems to report warnings as gcc does. But I guess it a little weird to report a warning when we enter in a system header in nonsystem via a digit directive. I mean there is no way (except may be `pragma`) to silently use a gnu digit directives because at the first use we are definitely not in a system header

Regardless of what behavior is expected isn't it better to change the `#` line numbers to prevent collision (may be to something like `current_physical_line+constant`)?

Start with clang/test/Preprocessor/line-directive-system-headers.c and clang/test/Preprocessor/line-directive.c, running the tests both with and without -verify as described. Trace the numbered diagnostic locations and determine whether repeated #line locations allow warnings to satisfy the wrong expectations; done means the tests unambiguously validate the intended compiler behavior.

Written by the indexing model from the issue text.