integrated Incrementalist into build pipeline

[Aaronontheweb]

Going to test this first before I get too excited, but a skunkworks project I've been developing behind the scenes is now ready for prime-time to help make life easier with Akka.NET:

https://github.com/petabridge/Incrementalist

Incrementalist uses Rosyln and the Libgit2 APIs to detect which projects are actually affected by every code change and determines the minimal working set needed to cover all of those aforementioned changes.

This means that if you submit a patch to our docs, we won't run any unit tests. If you make a patch to Akka.Cluster.Sharding, only the Akka.Cluster.Sharding tests and multi-node tests have to run. If you make a change to Akka.Streams, only the modules that take Akka.Streams as a dependency run on our CI services.

With the exception of working on the core Akka.NET module or modifying the Akka.sln file itself (which this PR does), you should never have to run the full test suite on a build ever again.

[Aaronontheweb]

Looks like we got bit by https://github.com/dotnet/cli/issues/9114 on both platforms - the Roslyn agent used for detecting MSBuild runtimes is scooping up the old .NET Core 1.1* SDKs on these machines.

[Aaronontheweb]

Looks like TeamCity is being goofy with its git checkout now and pruning branches we need - this issue does not occur on Azure Pipelines. Going to see if there's a setting I can change to fix that. Had one build stage (continuous-integration/windows-multinode-tests-netcore) succeed and find the dev branch, but not others. It had a different configuration in TC where cleaning wasn't enabled. Going to look into it. Worst case scenario: I might need to kill off 100% of the agents and restart them before attempting again.

[Aaronontheweb]

Ok, got this fixed - so TeamCity does some messed up stuff with how it fetches the git repository but we can fix it by having the agent call the following prior to executing any of our FAKE build instructions:

git fetch -all

That will pull down the dev branch, which we need for making comparisons for the diff. I'll update all of the TeamCity configurations to do this and then run it accordingly.

[Aaronontheweb]

Added an additional stage - in the event that node code changes were detected (i.e. someone fixed a typo in the documentation) we won't even run the compilation or restore stages on builds.

[Aaronontheweb]

TeamCity just died - license expired in the middle of running these builds (wasn't aware of any notifications of the sort.) Going to prepare to move us onto Azure DevOps pipelines (as has been the plan) right away then, but I want these changes in so I can move forward with a clean slate. Can revert them later if need be, but CI is offline until I get this fixed