Cumbersome long filenames in show of coverage report.

When running a coverage report, the filenames printed contain the full path, not just the path relative to the project root. I'm not sure if this is intentional, or a problem related to my system setup specifically. (Running coverage over LocalRegistry as it's an Open Source project I happened to have open at the time.)

┌────────────────────────────────────────────────────────────────────────┬───────┬─────┬──────┬─────┐      
│ Filename                                                               │ Lines │ Hit │ Miss │   % │      
├────────────────────────────────────────────────────────────────────────┼───────┼─────┼──────┼─────┤      
│ C:\\Users\\12345678\\.julia\\dev\\LocalRegistry\\src\\LocalRegistry.jl │   261 │ 250 │   11 │ 96% │      
├────────────────────────────────────────────────────────────────────────┼───────┼─────┼──────┼─────┤      
│ TOTAL                                                                  │   261 │ 250 │   11 │ 96% │      
└────────────────────────────────────────────────────────────────────────┴───────┴─────┴──────┴─────┘ 

I hacked a small implementation that removes the summary.pkgdir from the filename. This did require some juggling with the case of the drive letter (on Windows...), which did trigger me to think that maybe that was the only cause of the issue.

The output I get with my hacky fix is

┌─────────────────────────┬───────┬─────┬──────┬─────┐
│ Filename                │ Lines │ Hit │ Miss │   % │
├─────────────────────────┼───────┼─────┼──────┼─────┤
│ \\src\\LocalRegistry.jl │   261 │ 250 │   11 │ 96% │
├─────────────────────────┼───────┼─────┼──────┼─────┤
│ TOTAL                   │   261 │ 250 │   11 │ 96% │
└─────────────────────────┴───────┴─────┴──────┴─────┘

So is the default behaviour I see intentional? And if so is the fix I implemented welcome?

Reproduce the coverage report using a project with a long Windows-style path, then trace where the report formats filenames relative to the project root. Compare the current output with the relative-path output shown in the issue; done means the report avoids unnecessary absolute-path prefixes without breaking path handling.