Use Uri.LocalPath instead of Uri.AbsolutePath for file IDs

[bamarsha]

For a file path containing spaces, like C:\Foo Bar\Baz.qs, that was converted to a URI file://C:/Foo%20Bar/Baz.qs:

• AbsolutePath returns C:/Foo%20Bar/Baz.qs
• LocalPath returns the original C:\Foo Bar\Baz.qs

Since the file ID is used as a path in C# generation with the #line annotations, using AbsolutePath was causing Q# projects to fail to build if EmbedAllSources was set to true in the project file, because the C# compiler would follow those annotations. The path given by AbsolutePath is not equivalent to the original file path, so the file couldn't be found. I think using LocalPath for all file IDs makes more sense here.

A corresponding PR microsoft/qsharp-runtime#263 is needed at the same time. The tests for this change are also there. Fixes #333.

[filipw]

this is a great idea. I started doing the exact same thing as part of #356 but then abandoned it as I wasn't sure what would I break in the runtime ☺️

[bamarsha]

@filipw Sorry about that, I didn't realize your PR was so similar, or I would've mentioned you. :)

Out of curiosity, is testing changes/making PRs across multiple repos something you are interested in? It is currently difficult for non-Microsoft-Quantum contributors to do this because our multi-repo integration repo is private at the moment, and I believe that only employees can publish packages to the alpha NuGet feed (which is how I updated the runtime package versions in this PR). I'm trying to advocate for making this integration repo/packaging process public sooner rather than later to help open-source contributors. :)

[filipw]

Out of curiosity, is testing changes/making PRs across multiple repos something you are interested in? It is currently difficult for non-Microsoft-Quantum contributors to do this because our multi-repo integration repo is private at the moment, and I believe that only employees can publish packages to the alpha NuGet feed (which is how I updated the runtime package versions in this PR). I'm trying to advocate for making this integration repo/packaging process public sooner rather than later to help open-source contributors. :)

yes, that would extremely helpful

[bamarsha]

yes, that would extremely helpful

Great, thanks for the feedback! I'll pass this along.

[bamarsha]

I have updated this PR:

• Add a new public method NonNullable<string> CompilationUnitManager.GetFileId(Uri uri) as an alternative to TryGetFileId. This is so Use CompilationUnitManager.GetFileId instead of Uri.AbsolutePath for file IDs iqsharp#175 can use GetFileId instead of directly accessing Uri.LocalPath - if we're treating file IDs as an opaque string generated by the compiler, downstream projects shouldn't need to know how it was generated.
• Deprecated TryGetFileId with the [Obsolete] attribute.

Here is my reasoning for deprecating TryGetFileId:

• After looking at how TryGetFileId was used in practice, it seemed like the majority of cases simply threw an exception if TryGetFileId returned false, which defeats the purpose of a Try-style method. In other cases, they defaulted to uri.AbsolutePath or uri.LocalPath, which would throw if uri is not an absolute URI anyway.
• The Try pattern only makes sense if both branches occur in practice at runtime (for example, if user input decides whether parsing a string succeeds or not). But I think in most or all cases of TryGetFileId, the URI is known to be of the right type (an absolute file URI). This is something the programmer should be able to control, so if TryGetFileId fails, it's a programmer error rather than a user error, and I think an exception makes more sense in that case.