[DSLX:LS] Fix/tighten up URI/path conversions, use VirtualizableFilesystem pervasively in DSLX

[cdleary]

Review note:

• most of this change is plumbing to ensure consistency with respect to the VirtualizableFilesystem layer and resulting consolidation (e.g. before we had get_contents lambda which is now subsumed by the VirtualizableFilesystem, and there are a few variants for common test uses of get_contents, like UniformContentFilesystem).
• the remainder of it is using a LspUri type to ensure types represent the conversion between filesystem paths and LSP URIs

---

We now have a wrapper type to indicate when things have been checked to be in URI form, and that type offers convenience APIs for conversion to string_view for the underlying and to std::filesystem::path to strip off the URI prefix.

Previously we ran into trouble in #1731 because the stdlib path was a relative path and pointed directly at the filesystem, and thus was clashing with the expectation that everything would be in URI form; i.e. a module would import a stdlib module and then that would have a filesystem (non-URI) path, and that would potentially import other stdlib modules with more filesystem (non-URI) paths.

We check as invariant in the file table that no URIs are held there -- the conversion into and out of URI form happens on the import boundary.

This PR also plumbs virtualizable filesystem into the error printing routines so they don't try to look at the real filesystem when they should be looking at the virtualized filesystem contents, e.g. in any error reporting done for parse errors encounterd by the LSP. Now that the LSP-parsed span filenames look indistinguishable from real filesystem filenames we have to be more careful to always try to use the virtual filesystem abstraction instead of xls/common/file/filesystem.h routines in retrieving file contents.

This, as a result, plumbs the virtual filesystem in everywhere to places that GetContents is called to ensure consistency across the DSLX facilities. In general we shouldn't need to rely on //xls/common/file:filesystem as a dep except in tools that write output files (as the VirtualizableFileSystem doesn't have SetContents). Note that usually there is an ImportData around somewhere, as it is a fairly primordial context-like object, and there is a vfs() hanging off of that.

Ran clang-tidy and bant dwyu

[hzeller]

Very nice!

Running xls/dev_tools/run-clang-tidy-cached.sh, I do get a bunch of missing includes for some of the referenced filesystem classes or some of the system includes such as <string_view>, so maybe that needs some attention (grep misc-include-cleaner xls_clang-tidy.out).

(I found that our current way of building the compilation DB has issues (at least on Linux) to properly succeed because it is confused about the dylib stuff, so I found on Linux I have to comment out in xls/public/BUILD while building the compilation DB/running clang-tidy-cached)

#libxls_dylib_binary()
#pytype_test_test_c_api_symbols()

)

[cdleary]

Very nice!

Running xls/dev_tools/run-clang-tidy-cached.sh, I do get a bunch of missing includes for some of the referenced filesystem classes or some of the system includes such as <string_view>, so maybe that needs some attention (grep misc-include-cleaner xls_clang-tidy.out).

Fixed almost all actionable clang-tidies outside of contrib, PTAL.

[meheff]

Running xls/dev_tools/run-clang-tidy-cached.sh, I do get a bunch of missing includes for some of the referenced filesystem classes or some of the system includes such as <string_view>, so maybe that needs some attention (grep misc-include-cleaner xls_clang-tidy.out).

The github PR to google internal submission is already cumbersome so I think we should avoid adding the additional requirement of keeping things include clean. Include cleanliness, in general, is of small value (not zero, but small). I don't think it is worth people's time to either check for cleanliness on PR's or go much out of your way to fix them. We have tools internally which can better handle these cleanups such as automatically flagging them in code review and transforming the code automatically. We can do this on a regular cadence internally if we care enough.