LanguageServerProjectSystem does not restore based on changes to transitive PackageReferences

**Version Used**: f2649bb1de58f2ab1e7a114ebcb00f5cb140560b

**Steps to Reproduce**:

1. `dotnet new classlib -o MyLibrary`
2. `dotnet package add Newtonsoft.Json --project MyLibrary`
3. Create an `app.cs` file like the following
```cs
// #:project MyLibrary // start with this commented out, then edit to comment it in
using Newtonsoft; // error expected to go away via transitive package reference

Console.WriteLine("Hello World!");
```
4. Verify expected command line behavior with `dotnet run app.cs`. The app builds successfully.

**Expected Behavior**: The project system restores assets when transitive dependencies change.

**Actual Behavior**: No restore is performed based on transitive dependencies, only direct dependencies.

The reverse also occurs, e.g. if you restore separately in the final state, like by using the CLI explicitly, then delete the `#:project` directive, the transitive dependencies will linger unexpectedly.

Fixing this may be tricky. I think there would be a need to track and watch a transitive closure of all the projects being referenced, to see if any of their package references change. Possibly msbuild has some way of making this easy for us, but, I didn't see an obvious point to get the transitive `PackageReference`s in `ProjectFileInfo`.

See [`ProjectDependencyHelper.CheckProjectAssetsForUnresolvedDependencies()`](https://github.com/dotnet/roslyn/blob/4ec123dd0e25e8d607190bf1aa88d9d780a524da/src/LanguageServer/Microsoft.CodeAnalysis.LanguageServer/HostWorkspace/ProjectDependencyHelper.cs#L51).

One thing we may want to consider doing here, is simply providing an editor command, which is available with or without DevKit, that just does a restore on the current FBP (if the current file is an FBP). So that if things are out of whack for or any other reason, user can at least just run that command. (A task which wraps `dotnet restore ${file}` would also work, if one knew to do it, I guess.)

This area is also light on testing. I think what we'd like to do, is add some "sanity" tests around restore behaviors for FBPs, to the vscode-csharp repo, which can run with+without DevKit. And then perhaps for some of the more intricate behaviors/fixes, we might be able to come up with a test harness for the `LanguageServerProjectSystem`/`FileBasedProgramsProjectSystem` specifically.