[FCS] `CheckResults.GetDeclarationLocation` returns nonsensical locations for files that have sourcelink enabled

I've been working on enabling support in FSAC for [using embedded or pdb-provided sourcelink information to power go-to-declaration/implementation without decompilation of dlls](https://github.com/fsharp/FsAutoComplete/pull/508). As part of this, I use the `CheckResults.GetDeclarationLocation` API from FCS to get the location of the declaration of a particular ident island in some source code. There are a few oddities I see with this API especially with respect to sourcelink:

* There's not a distinct return case on the `FSharpFindDeclResult` to mark that you as the client should attempt a sourcelink lookup. This is because the API currently returns `FSharpFindDeclResult.DeclFound` with a `range`.
* The `range` returned as part of the `FSharpFindDeclResult.DeclFound` may not exist in the user's system, because the range reported in this case is from the full path of the host that _built_ the assembly. For example, taking the `button` function from Giraffe's ViewEngine module at version 4.0.1 as an example, the path reported for the file containing the member is `C:\projects\giraffe\src\Giraffe\GiraffeViewEngine.fs` (sorta, read on),
* The `range` reported is nonsensical in that it contains duplicated 'build root' portions. The _actual_ filename reported in the example above is `C:\projects\giraffe\src\Giraffe/C:\projects\giraffe\src\Giraffe\GiraffeViewEngine.fs`, which has a duplicated `C:\projects\giraffe\src\Giraffe` portion coupled with a unix-style `/` path separator.

**Repro steps**

If you checkout the PR above and run `dotnet run` from the `test/FsAutoComplete.Tests.Lsp` directory, the tests I have written for Giraffe will fail due to the above reasons.

**Expected behavior**

The API should provide a signal that Sourcelink has been provided or that the range is non-local in some way, or
The API should provide a range that is consistent with the path that sourcelink is configured to expect (i.e. no duplicate root portions or incorrect separators).

If we had option A, then we could detect the need to try sourcelink more easily, but if we had B we could workaround the existing API.

**Actual behavior**

The above ranges are returned and it becomes very hard to work around the invalid paths in a consistent way.

**Known workarounds**

🍺

**Related information**

Provide any related information (optional):

* Operating system: Mac OSX 10.14
* .NET Runtime kind: .Net Core 3.x
* Editing Tools: VS Code/Ionide/FSAC