Build should block on restore completion

From internal email:

> We’re having a problem with MAUI projects when changing between debug targets that have different RuntimeIdentifiers. After updating the RID value the project is targeting, we need to run a NuGet Restore so the project.assets.json file is updated.
>
> For context, when the debug target is changed, we update the RuntimeIdentifier value in the csproj.user file. This change starts a NuGet restore, but there’s a lapse of time in between we make the change and the NuGet Restore process starts and completes in which the project is in an invalid state (the RID in the project is different than in the project.assets.json file), and the user can try to run/build the project.
>
> If the user builds the project in that state they’ll get the NETSDK1047 build error, stating the selected RID is not present in the project.assets.json file.

Analysis from @davkean:

> We have the same problem if you update the TFM and immediately build.
>
> I think something on the .NET Project side or CPS side should block build (via [RegisterAsyncTask](http://index/?query=RegisterCritical&rightProject=Microsoft.VisualStudio.ProjectSystem&file=Core%5CThreading%5CIProjectAsynchronousTasksService.cs&line=77)) on restore data being up-to-date with the latest version of the project file.

Analysis from @lifengl:

> I guess net core project side can handle this, because it knows when NuGet restore ends for the project. To ensure there is no time gap, the critical task might need be registered during ProjectChangedSynchronous event.
>
> And, we need ensure fast build up to date check won’t skip the build completely in this case too.