Do not fall back to legacy dependency resolution logic if `.deps.json` file exists.

### Summary

Increase predictability of task dependency resolution, by _exclusively_ relying on the task's `.deps.json` file, if it exists.

### Background and Motivation

For a long time, MSBuild has [supported](https://github.com/dotnet/msbuild/blob/main/documentation/specs/task-isolation-and-dependencies.md#task-dependency-resolution) resolving a task's dependencies using the `AssemblyDependencyResolver` class, if the task's assembly is accompanied by a `.deps.json` file. This is much more reliable than the previous logic, which has a number of reported issues like #6993 and #12370.

While looking at #12370, I noticed that in tasks with a `.deps.json` file, we still [fall back to the previous logic](https://github.com/dotnet/msbuild/blob/0bc107d17d1ced549df27a7423702b138231686c/src/Shared/MSBuildLoadContext.cs#L57-L62) if a requested dependency could not be resolved, and I wondered whether this is the right thing to do, and if we should skip it and return `null`.

### Proposed Feature

The following code path https://github.com/dotnet/msbuild/blob/0bc107d17d1ced549df27a7423702b138231686c/src/Shared/MSBuildLoadContext.cs#L57-L62

is replaced with:

```csharp
// respect plugin.dll.json with the AssemblyDependencyResolver
if (_resolver is not null)
{
string? assemblyPath = _resolver.ResolveAssemblyToPath(assemblyName);
if (assemblyPath != null)
{
return LoadFromAssemblyPath(assemblyPath);
}

return null;
}
```

We will likely need a change wave for this.

### Alternative Designs

_No response_