Add tooling to ensure no API changes are made in patch updates

[natemcmaster]

Follow-up to #3610

We should add tooling so we can ensure that 3.0.1, 3.0.2, etc do not change any public API in the reference assemblies.

[Pilchie]

@dougbu can you take a look at this? Or maybe @anurse can nominate someone else?

[analogrelay]

I'm not sure this is something we'd have resources to support in preview 8 given the very short timeline. We could look at it as part of infrastructure work in preview 9 though since getting infra-/test-only changes through ask-mode should be much simpler. We already have some things we want to do to improve API changes all up, so this would be part of that work.

[Pilchie]

Fair enough, I'll move to Preview 9

[dougbu]

Also compare implementation and ref/ assemblies to be sure we don't mess anything up in our *.Manual.cs files.

[dougbu]

dotnet/arcade@d6dd7a000fe9 is now in. Next steps are

1. wait for change to be verified as repos take new Arcade dependencies in their 'master' branch
2. port change to Arcade's 'release/3.x' branch
3. pick up the new Arcade packages in our 'release/3.1' branch
4. take advantage of new Arcade features❕

This may not be 💯% complete in time for 3.1.4 and isn't really part of a 5.0.x release. Moved to 3.1.x

[dougbu]

After a few conversations with others who have made changes to *.Manual.cs files, I'm going to close this w/ no action. Nobody expects to need more than surgical implementation fixes later in 3.1. Even if changes are necessary, they'll almost definitely take much less effort (all together) than fixing this issue.

Background: Of the two possible ways to avoid needing the *.Manual.cs files,

1. Back-porting GenAPI fixes needed to generate better C# files automatically will take much, much more work than expected future changes the files.
2. Switching to use Roslyn to build ref/ and implementation assemblies simultaneously will likely take much less effort but will perturb our assembly versioning. Right now, only the ref/ assemblies have fixed Major.Minor.0.0 versions. Not sure what problems we'd hit if the implementation assemblies in later 3.1 releases had lower assembly versions.