Allow VS package version to be explicitly set when running the build pipeline

[AdamYoblick]

Related to #8138

VS doesn't allow your package version number to be lower in VS versions that are higher. For example, we are trying to insert into 17.10. But because we have a version that got snapped to 17.12 (from VS main), and that version is lower than the version we're trying to insert into 17.10, we get an error in the PR.

The root cause of this is that we generate our PTVS package version numbers from the azdo pipeline build number, which is an environment variable Build.BuildNumber. And the build numbers are always increasing. We do this because 1) the build number is guaranteed to be unique, and 2) it provides an easy way for us to trace an insertion PR back to a PTVS build.

But that approach breaks down when we are trying to hotfix a particular VS release branch without hotfixing all of the the higher branches. This is the first time we've run into this issue.

The correct way to fix this would be to allow us to set the package version number when kicking off the build pipeline, and do the same with the release pipeline. That way, inserting into 17.10 won't have the highest version number just because it ran more recently. Instead, we would be able to do (version in 17.10) + 1, and everyone is happy.

So that's what I'm planning on doing. If you don't specify the version number, it will just use the build number. But if you do specify it, it will use what you provide.

There are a few places that this value needs to be plumbed through the build scripts, since some of them read directly from the environment. Search for Build.BuildNumber or Build_BuildNumber in the repo to find them.