Suppression matches inlined positions

[som-snytt]

The inlined stack includes the nonInlined pos itself, which is filtered by rendering.

Fixes #24082

Why was the ticket worth tackling?

Local warning suppression must work with inlining. Otherwise, users must choose whether to forego warnings (which are an optional feature) or inlining (which may not be optional for a particular use case).

How I fixed it

How does @nowarn know what to suppress? A Suppression is registered with the current Run, and when reporting, a Suppression matches a given diagnostic based on position. The diagnostic position knows its "enclosing" inlined positions, so a suppression should also match those positions.

Why is this PR worth reviewing?

It's a one-liner that enables important feature interop.

What's the worse that could happen?

It can only suppress additional diagnostics, so at worst it results in false negatives, which are preferable to the alternative.

[som-snytt]

It's no longer a one-liner. The motivation to refactor is in the commit to "use adjusted pos": it's hard to keep track of what position is used at any point.

To summarize, there is the pos of the diagnostic (which is arbitrary), the adjusted position to render at (the most specific pos at the user call site, adjusted at EOF), and the positions in the inline stack of the diagnostic pos which are not contained by the user call site (the outermost pos) and which will be displayed in the supplemental stack trace.

Some subtleties include whether the "max line" (for determining the offset of the box, to accommodate the digits) is 10 if the last line is 9 (for error at EOF, as noticed by chance by a test).

There are more intermediate strings to eliminate by using the implicit StringBuilder.