Fix some additional minor nullability issues

[bamarsha]

These are a few minor nullability issues that don't seem to be caught by the C# compiler or Visual Studio, but Rider marks them as errors. They seem to be legitimate issues, so here are some fixes:

• ExternalRewriteSteps.cs: T could be a value type, in which case unboxing the potentially null result from ?.Invoke could throw an exception. Using default handles both value and reference types without errors.
• ProjectLoader.cs: p.Name is known to be not null here, but p.Name?.ToLowerInvariant() implies that it could be null, and should convert the type from string to string?. But the value is used as a dictionary key which must be non-null.
• LanguageServer/Utils.cs: TResult may be null, but it is not known to be either a value type or a reference type, so it's not possible to use TResult?. A [MaybeNullWhen(false)] out parameter can't be easily used either, because local functions don't support attributes until C# 9. The simplest thing here seems to be to use the null-forgiving operator, because the return value is used safely in the code below.

[azure-pipelines]

No pipelines are associated with this pull request.

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[swernli]

Looks good. I hadn't actually known about the default literal before, very cool to see it used here!