Use same logic as dotnet restore/build for dependency resolution

[coderpatros]

This is going to be another large pull request, sorry @stevespringett :/

This will resolve issues #27 and #15. And is based on PRs #41 and #39

A few positive points of note:

• individual package resolution should be a lot quicker, we're now using the local nuget package and nuspec cache, although this resolves all dependencies now, so it can actually take longer overall
• correct BoM contents because this uses the same project.assets.json file produced by the dotnet restore command and consumed by the build process
• version ranges are now handled due to the above point
• custom/private project nuget sources now supported out of the box as above
• improved nuspec and license expression parsing by using nuget libraries

But, this could result in some issues being raised.

For example...
We have one project that with the old project file reference and nuget resolution method had 7 dependencies. Now that it factors in everything it is reporting 179.

Part of this is because the standard libraries, like the Microsoft.* and System.* packages, weren't being included but they are now.

This seems like a massive change because of the line counts. But most of that is just test data. I've also added a test step timeout of 10 minutes. I had inadvertently introduced an async deadlock that was only evident when running on Windows or in the GitHub Linux agent.

[stevespringett]

#65 was merged. Would it be possible to resolve the conflict?

[stevespringett]

Also, when will this PR be ready to merge? Still a work in progress?

[coderpatros]

@stevespringett the code itself is good to go. Just want to make sure the github actions work as expected.

[coderpatros]

This includes #71

[coderpatros]

@stevespringett all checks have passed so should be good to merge this now. Although I'll probably create another PR a bit later tonight that includes all the dependency bumps as well.