MicroBuild v2: Fix binary and package version metadata; refactor and improve scripts.

[dilijev]

MicroBuild v2: Fix binary and package version metadata; refactor and improve scripts.

Binary and Package Versions

Binary File Version Metadata

Enables correct embedding of version string in file info. All binaries will now
embed File Version metadata as follows:

<MAJOR>.<MINOR>.<PATCH>.0 (<branch>:<hash>.<build_high>.<build_low>.<push_date>)

Example:

1.2.1.0 (release/1.2:9786fcdbcaa6963a5ccc6648b7aa9bd9dd51d9ec.00008.12122.161007-1756)

MAJOR, MINOR, and PATCH correspond to SemVer fields and will match the
version of ChakraCore the package corresponds to. The fourth field would have
been used to indicate security fixes (a.k.a. QFE) but because a fourth field
is not allowed in NuGet package version numbers, but is standard for versions of
binaries produced from VS projects, we are keeping the fourth field in the
binary data and locking it to 0, and omitting it from NuGet package version
numbers and release numbers from now on.

Release NuGet Package Versions

The format of version strings for released NuGet packages will continue to be:

Microsoft.ChakraCore.<MAJOR>.<MINOR>.<PATCH>.nupkg

Example:

Microsoft.ChakraCore.1.2.1.nupkg

Preview NuGet Package Versions

The format of version strings for preview NuGet packages will now be:

Microsoft.ChakraCore.<MAJOR>.<MINOR>.<PATCH>-<SPECIAL>.nupkg

Where <SPECIAL> is:

preview-<build_high>-<build_low>

This solves the problem of getting enough information into the package preview
version string (<SPECIAL>) to order builds correctly while still guaranteeing
that we fit the requirements for the <SPECIAL> field:

1. It must start with a letter
2. It can only contain the characters [a-zA-Z0-9-]
3. It must be 20 characters or less

Example:

Microsoft.ChakraCore.1.2.1-preview-00008-12122.nupkg

Miscellaneous Version-Related Changes

Add PATCH version to CommonDefines.h so that it doesn't need to be manually
coded into builds. (By reducing user intervention for package versions we make
it more feasible to automatically release preview packages from multiple
branches.)

Extract MAJOR, MINOR, PATCH, and QFE version numbers from the source
code by grepping for values of the #defines that correspond to those values.

Refactorings and Script Parameters

Merge pogo_build.ps1 into run_build.ps1. Passing the required pogo-related
flags to run_build.ps1 produces a POGO build. No need to have separate
scripts.

Compute ObjectDirectory and use that for Chakra.Generated.BuildInfo.props
unless TF_BUILD_BUILDDIRECTORY is specified in the PATH.

Infer $binpath.

For many parameters that were previously specified as environment variables from
the environment of the build infrastructure, it is now possible to specify them
as script parameters directly, where script parameters will take precedence over
the values of the corresponding environment variables. This can be helpful when
running scripts manually where you want to quickly experiment with the value of
a variable without having to write it to the environment first. Since it is
sometime valuable to get that variable from the environment, if the script
parameter is unspecified, the value of the environment variable will be used
instead. Additionally, if any parameter is unspecified by either script
parameter or environment variable, a reasonable default is encoded in the script
logic.

In order of precedence, all values will be determined by checking for values in
the following order, if applicable:

1. Script parameter
2. Environment variable
3. Script logic to retrieve value
4. Default value

Add parameters with corresponding environment variables to specify skipping
certain paths through the build scripts, which can save time when testing
certain changes by ignoring expensive but unimportant parts of the builds.
Specifying an environment value at the time the build is queued is easier than
modifying the build definition, so adding the environment variable option adds
convenience when testing with the production build definitions.

• run_build.ps1 -skipPogo or set SKIP_POGO to a non-empty string will skip
  the POGO phase of the build, if it would have been a POGO build. Useful if the
  build binaries produced at the correct locations is enough and you're most
  interested in testing the non-POGO-related aspects of the build scripts.
• post_build.ps1 -skipTests or set SKIP_TESTS to a non-empty string will
  skip running tests, which can be lengthy. This is useful if the quality of the
  binaries produced is not important and you're interested in testing other
  aspects of the build scripts.

Miscellaneous

Reduce dependencies on data from build server environments so that these scripts
can be used to perform local builds.

Update UseValueOrDefault to take any number of arguments.

Reduce dependency on locate_msbuild.ps1.

Add $BuildSubtype to 'not enough info' error.

Check for the existence of nuget.exe before trying to invoke it. This helps
when running in environments where NuGet is not installed or is not available.
Can avoid errors related to NuGet package restore when running on a build server
with a custom NuGet location and a specific NuGet Task separate from our
scripts. Keeping the NuGet invocation in our scripts allows us to still do local
builds without MicroBuild infrastructure configured on the dev machine (we don't
take a hard dependency on the aforementioned NuGet Task.

[dilijev]

@boingoing please review :)