Make the AssemblyVersion does not change for servicing releases - #24667

PR Context

Make the AssemblyVersion does not change for servicing releases.

Today, the AssemblyVersion of the PowerShell assemblies keeps changing when there is a new servicing release, for example, for PowerShell v7.4.3, the AssemblyVersion is 7.4.3.500, and for PowerShell v7.4.4, it becomes 7.4.4.500. Accordingly, the AssemblyVersion of the reference assembly from the NUGET packages released from each servicing release also keeps changing.

This causes a problem: for a module that depends on PowerShell 7+ NUGET packages, every time it moves to a newer version of NUGET package, it would require a higher version of PowerShell to work. For example, when a module is built against the v7.4.4 of the System.Management.Automation NUGET package, the user would need to have PowerShell v7.4.4 or higher to use the module.

However, in most cases, we need to update the dependency of a module only due to the compliance requirements -- you need to use the most recent version of a NUGET package when it's available, but the module itself doesn't have any security issue and should work just fine on any v7.4.x PowerShell. Requiring the user to always on the latest PowerShell to use a module is unnecessary.

.NET keeps the AssemblyVersion of their framework assemblies unchanged for servicing releases (8.0.0.0 for System.Private.CoreLib.dll or System.Threading.Thread.dll for .NET 8.0.10), and so should we. This PR updates the build a bit to make the AssemblyVerseion of PowerShell assemblies unchanged for servicing releases, so that moving to a newer version of NUGET package to build a module doesn't require a higher version of PowerShell for the module to work.

PR Summary

Explicitly set the FileVersion and AssemblyVersion properties when the release tag is passed in. FileVersion is kept the same as PSCoreFileVersion like before, and AssemblyVersion is set to be PSCoreFileVersion with the Build field setting to 0.

BREAKING CHANGE

This will be a breaking change if we back port the change to PowerShell 7.4.
A module or an application that is built targeting an existing 7.4.x PowerShell NUGET package will not work with a new servicing release after porting this change to 7.4, because the new AssemblyVersion will become 7.4.0.500 but the module/application depends on 7.4.4.500 for example, which is higher.
However, we can make it non-breaking to 7.4 by change the Build field to 500 (for example) when backporting to 7.4.

This is NOT a breaking change for 7.6 preview or for back porting to PowerShell 7.5.

Build Validation

Coordinated package build: https://dev.azure.com/mscodehub/PowerShellCore/_build/results?buildId=550558&view=results
Packages pipeline: https://dev.azure.com/mscodehub/PowerShellCore/_build/results?buildId=550722&view=results

The build branch name is release/v7.4.9, and the AssemblyVersion of PowerShell assemblies is 7.4.0.500, and the reference assembly produced in the nupkg build step also has AssemblyVersion to be 7.4.0.500

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.
• Breaking changes
  • None
  • OR
  • Experimental feature(s) needed
    • Experimental feature name(s):
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    - [ ] Issue filed:
• Testing - New and feature
  • N/A or can only be tested interactively