Incremental Builds

[freddydk]

Support incremental builds

TODO

• Add release notes
• Add settings docs
• Add end 2 end tests
• Fix existing CI tests

Use git diff instead of API

In v6.1 and earlier versions, we use the GitHub API to determine last known good build and determine modified files in the Pull Request. It is however possible to have done modifications to the main branch after the last known good build - the changes will not be included in the PR and this the PR builds will only include the modified files in the PR together with the last known good build - potentially missing files.
This version locates the SHA, which was used to build the last known good build and uses git diff to determine all changes from that build including the changes in the PR to build what's needed.
git diff also supports many more files than the API, is faster and it doesn't count as API calls against the GitHub limit.

Changed Schedule to workflowSchedule

Instead of using dynamic setting key name - use a workflow specific setting and deprecate the old keys.

Add concurrency protection to workflows

Add new workflow specific setting called - workflowConcurrency. It is used to control concurrency of workflows.
Like with the WorkflowSchedule setting, this setting should be applied in workflow specific settings files or conditional settings. By default, all workflows allows for concurrency, except for the Create Release workflow. If you are using incremental builds in CI/CD it is also recommented to set WorkflowConcurrency to:

[
  "group: ${{ github.workflow }}-${{ github.ref }}",
  "cancel-in-progress: true"
]

in order to cancel prior incremental builds on the same branch.
Read more about workflow concurrency here.

Remove warnings that tests doesn't exist if doNotBuildTests is true

No reason to warn about missing test apps if you don't want to build them anyway

Remove warnings and error when locating previous builds

Getting rid of warnings like this:

due to DownloadProjectDependencies downloads artifacts double

and errors like:

if there wasn't a successful build in the repo.

Check whether a package has been delivered to GitHubPackages or NuGet before delivering

If the package already exists in the current version it has already been delivered (might be from an earlier build)

[mazhelez]

Except for the few comments around tests, the PR looks ready to me.