Add property function GetStableHash for String

[rainersigwald]

Some projects wish to include hashes of strings (often paths) in output folder names, which must be defined at evaluation time. System.String.GetHashCode is available but unsuitable for many desirable purposes: it's documented to vary across 64- and 32-bit .NET implementations and can also vary between .NET Framework and .NET Core.

MSBuild has an internal method to get a stable hash that's currently used for IPC

https://github.com/microsoft/msbuild/blob/fa773bb8d44a358963481c02e772509dc408a6d9/src/Shared/CommunicationsUtilities.cs#L673-L707

We should expose it as $([MSBuild]::StableStringHash()).

Open questions:

• Name
• Should we override calls to String.GetHashCode()?

[Forgind]

This part looks like something that would cause me problems if I didn't know about it previously. I'd prefer to override System.String.GetHashCode.

[dasMulli]

Would authors using this hash code be happy with String.GetHashCode() behaving differently between msbuild versions? This may add another unexpected (?) dimension to the differences matrix until every system is updated; all dev tools (vs/cli/vs-mac/rider) as well as CI systems.
From an API perspective it would make more sense to add a new API and offer build authors the possibility to require a minimum MSBuild version or condition on the current version instead of playing a "what tool is build me"-roulette.

[Forgind]

That's true. I don't like how GetHashCode works now, but it's also good to avoid unexpected changes. If we were to add a System.String.HashCode that generates a stable hash in addition to System.String.GetHashCode, that would resolve the problem.

On the other hand, the warning I pasted previously explicitly says not to use them outside the application domain or persist them, so this might not be a problem. Also, if hashes are expected to "differ across .NET implementations," this just seems like more of the same.