[build] Always use 4-tuple versions (dotnet#901)

Context: 2d5431f

Commit 3e6a623 inadvertently "broke the world" by causing the
version of `Java.Interop.dll` to change to 0.1.2.0, which was
backward-compatible -- older assemblies would work with newer code --
but not [forward compatible][0]: you couldn't build an assembly
against the latest version of Xamarin.Android and use it with older
versions of Xamarin.Android, as 0.1.0.0 couldn't satisfy 0.1.2.0.

This was doubly unfortunate, as `Java.Interop.dll` hadn't changed.

This was fixed in commit 2d5431f, by "simply" resetting the
`$(Version)` MSBuild property of `Java.Interop.dll` & co. back to
0.1.0.0.

*However*, commit 2d5431f introduced it's own (smaller) breakage:
the `[assembly: AssemblyFileVersion]` value was wrong.

This didn't break anything, but does makes for a rather "odd"
experience when looking at the Java.Interop.dll Properties panel
within Windows Explorer:

![Java.Interop.dll Properties](https://user-images.githubusercontent.com/179295/138962305-18ddf670-97b9-4040-bc39-653d82ddf32d.png "File version: 0.0.0.0")

The **File version** value is shown as 0.0.0.0.

The File version value is shown as 0.0.0.0 because the value is
actually *invalid*; it's a "5-tuple", with the generated
`AssemblyInfo.g.cs` containing:

	[assembly: System.Reflection.AssemblyFileVersionAttribute("0.1.0.0.0")]

This "5-tuple" doesn't result in a compilation error, but does cause
the file version information to not be set at all.

Commit 2d5431f encountered a similar scenario with
`[assembly: AssemblyVersion]`, which resulted in a CS7034 error:

	error CS7034: The specified version string does not conform to the required format - major[.minor[.build[.revision]]]

Commit 2d5431f fixed the CS7034 by removing a `.0` from
`AssemblyInfo.g.cs.in` for `[assembly: AssemblyVersion]`, but
neglected to remove the `.0` from the similarly structured
`[assembly: AssemblyFileVersion]` line.

Fix the File version value in the Java.Interop.dll Properties dialog
by doing two things:

 1. Update `AssemblyInfo.g.cs.in` so that
    `[assembly: AssemblyFileVersion]` doesn't append `.0`, thus
    ensuring that `Java.Interop.dll` has a "4-tuple" value.

 2. Update the `GenerateVersionInfo` target in `VersionInfo.targets`
    so that the default replacement for `@VERSION@` is a 4-tuple.

This ensures that we consistently use 4-tuple Version values, and
fixes the Java.Interop.dll Properties dialog to show the correct
value for the File version property.

[0]: https://en.wikipedia.org/wiki/Forward_compatibility

Author: jpobst

build-tools/scripts/AssemblyInfo.g.cs.in

@@ -14,7 +14,7 @@ using System.Reflection;
 [assembly: System.Reflection.AssemblyCompanyAttribute("Microsoft Corporation")]
 [assembly: System.Reflection.AssemblyConfigurationAttribute("@CONFIGURATION@")]
 [assembly: System.Reflection.AssemblyCopyrightAttribute("Microsoft Corporation")]
-[assembly: System.Reflection.AssemblyFileVersionAttribute("@VERSION@.0")]
+[assembly: System.Reflection.AssemblyFileVersionAttribute("@VERSION@")]
 [assembly: System.Reflection.AssemblyInformationalVersionAttribute("@INFORMATIONALVERSION@")]
 [assembly: System.Reflection.AssemblyProductAttribute("@PRODUCT@")]
 [assembly: System.Reflection.AssemblyTitleAttribute("@TITLE@")]

build-tools/scripts/VersionInfo.targets

@@ -16,7 +16,7 @@
       DependsOnTargets="GitVersion"
       Condition="!Exists ('$(MSBuildThisFileDirectory)..\..\bin\Build$(Configuration)\Version.props')">
     <ItemGroup>
-      <Replacements Include="@VERSION@" Replacement="$(GitSemVerMajor).$(GitSemVerMinor).$(GitSemVerPatch)"/>
+      <Replacements Include="@VERSION@" Replacement="$(GitSemVerMajor).$(GitSemVerMinor).$(GitSemVerPatch).0"/>
       <Replacements Include="@COMMIT@" Replacement="$(GitCommit)"/>
       <Replacements Include="@BRANCH@" Replacement="$(GitBranch)"/>
     </ItemGroup>