Reevaluate the packages lock file + transitive project versions

[nkolev92]

Currently if you have a transitive projects, the transitive project will have a requested version for the project.
This would mean every project version change will require a lock file regeneration.

//cc @anangaur
@joelverhagen @zivkan @dominoFire @rrelyea

[nkolev92]

A bit of background:

The packages.lock.json model has 3 types of dependencies.

1. Project - project reference, both direct & transitive are written the same.
2. Direct - packages directly referenced
3. Transitive - packages pulled in transitively, either through project or package

Now a few things that cannot be understood from the lock file:

1. In the lock file there is no distinction between a project pulled in transtiively and a direct project reference.
2. For project dependencies, their dependencies are listed as well. However, you cannot figure out solely from that object (below) whether a dependency is a project or a package. You can look at the related changes however and figure it out because of the duality between project/packageids on NuGet side.

Relevant: https://github.com/NuGet/NuGet.Client/pull/2701/files#diff-4f61fe90f26719aa002d997eb1a92576

     "NuGet.Packaging": {
        "type": "Project",
        "dependencies": {
          "Newtonsoft.Json": "9.0.1",
          "NuGet.Configuration": "5.0.0-preview3",
          "NuGet.Versioning": "5.0.0-preview3"
        }
      },

Now after fixing a few bugs with the evaluation:

#7889
#7930
#8019

We now have the lock file up to date check verify that the project reference graph is the same.
However it does not verify the project versions.

The reason for this is because if we tried validating the versions, it would fail every CI build in locked mode.
We recommend that every build creates package with a different version, so even our CI would fail with this.

tl;dr;

The version for projects listed in the dependencies section is useless.
Furthermore it's very easy for it to get out of date. You could be building a

Removing it would require potentially changing the model of the lock file is written.
I can investigate if re-moving it is a no-op.
Unsure if this breaks any existing code if the file is not written with a project version.
I can investigate more if we think removing them is the right approach.

I don't expect any issues if we were to fix this in 5.2 though. If it breaks the model, we increment the file version. If it doesn't break the model, switching between versions could create noise, but eventually it should disappear.

[nkolev92]

Safe to say, this won't make it in 5.1. :)

[nkolev92]

Related: #8465