Add filePath when generates new Document in MoveTypeEditor

[Cosifne]

Fix #68550
MoveTypeEditor generate a new Document by providing

1. The containing folders of the old document
2. The new name of the document.
   This is not a problem in VS because we check if the folders exist https://sourceroslyn.io/#Microsoft.VisualStudio.LanguageServices/ProjectSystem/VisualStudioWorkspaceImpl.cs,793, then the document would be added to the folder.

However, in VS Code,

roslyn/src/Features/LanguageServer/Microsoft.CodeAnalysis.LanguageServer/HostWorkspace/LoadedProject.cs

Line 107 in 570b267

document => _projectSystemProject.AddSourceFile(document.FilePath),

when project system loads the document, it doesn't provide containing folder information. And we also don't check that when add a document to project. (We only check the file path, and if it doesn't exist, fall back to the project root)

roslyn/src/Features/LanguageServer/Protocol/Handler/CodeActions/CodeActionResolveHandler.cs

Line 288 in 570b267

: newTextDoc.GetUriFromProjectPath();

So we can fix the problem in two ways.

1. Parse the folders for all the documents in LSP, and also checking the containing folder when add documents in CodeActionHandler. And we don't need to change the MoveTypeEditor.
2. Let the MoveTypeEditor gives more information about the file path.

This PR fix the problem in the second way.

[jasonmalinowski]

@Cosifne: if we just implemented folder information in VS Code, would that make this problem go away?

[Cosifne]

@Cosifne: if we just implemented folder information in VS Code, would that make this problem go away?

@jasonmalinowski
If the folder information is provided in VSCode, we need to add one more extension method here

roslyn/src/Features/LanguageServer/Protocol/Handler/CodeActions/CodeActionResolveHandler.cs

Line 286 in a8a9811

var uri = newTextDoc.FilePath != null

e.g.

1. Check file path.
2. If file path is null, check containing folder. (This one is missing now)
3. Fall back to project root.

[jasonmalinowski]

@Cosifne We can close this in favor of #68995, right? I'm liking that approach so we should go ahead with that I think.

[Cosifne]

@Cosifne We can close this in favor of #68995, right? I'm liking that approach so we should go ahead with that I think.

Sure, I keep forgetting this PR 😅