Modify PrettyPrinter to output diagnostics using shortened relative paths

[TTOzzi]

Resolve #818

Modified PrettyPrinter's diagnostic logic to output diagnostics with shortened relative paths instead of full paths, as I believe this is more appropriate.

[ahoppen]

I’m a little skeptical of this. When forming a URL, we provide a baseURL and a path relative to it. Generally, I wouldn’t expect it to matter what’s part of the base URL and what’s part of the relative path. For example, I would have expected url = URL(string: url.absoluteString) to not have any effect on the output but with this change it does.

What I’d prefer instead is some way of stripping off a known base path from context.fileURL here (though I don’t have concrete suggestions of how to do so at the moment).

[allevato]

FWIW, this change would bring the pretty printer to be consistent with how we're using the relativePath property elsewhere.

When we create the SourceLocationConverter that the other non-pretty-printer rules use in Context.swift, we use the relativePath property.

Then, in FileIterator.swift, we have a bunch of logic that explicitly constructs the URLs this way. (In fact, I thought we were using FileManager.DirectoryEnumerationOptions.producesRelativePathURLs here, but that doesn't seem to be the case. That might have been historical, or there might have been a platform-specific issue that prevented it.)

[TTOzzi]

As @allevato mentioned, other parts of the codebase already use relativePath except for PrettyPrinter, so I thought it would be fine to change it to use the same property for consistency.

Would it be better to implement a separate logic to derive relative path, similar to what's done in FileIterator, and apply it across all rule diagnostics, including PrettyPrinter?

[ahoppen]

Oh, OK. I didn’t realize that we already used relativePath elsewhere. While I have the same objection still in principle, I don’t object to adding another use for it if there’s already precedence.