build.proj results in building projects repeatedly

[AArnott]

When using build.proj, the dotnet build, dotnet test, and dotnet pack commands are all used in succession, and each one builds the projects.

We could fix this by adding --no-build in front of the non-build commands, but then the build will fail if the user tries to build just the test target and the build hasn't been done (or is out of date).

The best way to fix this would be to either make build.proj actually build via projectreference so that msbuild will efficiently execute each project only once, or (even better, IMO) abolish the build.proj file entirely and just use dotnet build, dotnet test and dotnet pack and have those do all the work with just one step.

I'm willing to take this on, if approved.

[AArnott]

After #434 and #430 are merged, I believe the only thing left is to just delete build.proj and adjust the build yml file to run dotnet directly. For artifact collection, dotnet pack -c $(BuildConfiguration) should be all you need. But for purposes of building and testing everything, and since it's useful to see package restore as a separate step in Azure Pipelines so you can see how your build time compares to your restore time, I would recommend these sequential steps (each as its own task in the yml file)

dotnet restore
dotnet build --no-restore
dotnet test --no-build
dotnet pack --no-build

Once build.proj is removed, dotnet build and other tasks will "just work" without specifying the solution file as an argument because there will no longer be a build.proj to compete with the sln causing msbuild to require us to specify it. 👍

[MarcoRossignoli]

We should update also docs with new command to build/test repo i.e.

dotnet build -configuration Release/Debug  // build repo
dotnet test  -configuration Release/Debug  // run all tests
dotnet pack  -configuration Release/Debug  // produce nuget packages

cc: @tonerdo

[MarcoRossignoli]

fixed #434 #422