chore: implement build and release automation

[dbjorge]

This PR implements GitHub Actions Workflows to automate an initial set of PR checks and canary/production releases. It is modeled after the workflows in https://github.com/dequelabs/axe-core-maven-html, https://github.com/dequelabs/axe-core-npm, https://github.com/dequelabs/axe-core, and off discussion with @AdnoC about how certain internal Deque .NET builds work.

It is intended to work very similarly to existing build/release automation in the other similar libraries, except with everything based on GitHub actions instead of going through CircleCI. Specifically:

• The source of truth for the currently released version is a stub /package.json file (the version number is repeated in each non-test .csproj)
• Each PR will run build/checks/tests in a debug configuration (pull-request.yml) and produce packages for debugging purposes with version numbers like 1.2.3-development.f4aeb4fa83661e5a5b612abb25997c379919bbde
• Each push to develop (usually PR merge commits) will kick off the publish-canary.yml workflow, which repeats the build/tests in a release configuration, produces .nupkg artifacts for each library, and publishes them as pre-release NuGet versions with a version number like 1.2.3-alpha.1, where the final number comes from github.run_number.
• Production releases are kicked off by a human manually scheduling a create-release.yml workflow, which automates the creation of a PR from develop to master which uses commit-and-tag-version and conventional-changelog-cli to update version numbers and CHANGELOG.md appropriately.
• Each push to master (a PR merge commit of a PR created by create-release.yml) will kick off the publish-production.yml workflow, which works similarly to publish-canary except using a version number without a suffix (like 1.2.3) and which includes an additional publish-github-release job based on the similar circleci implementation from the example repos
• Closed PRs to master will also trigger the sync-master-develop.yml workflow to resync develop with the version update applied to master. This workflow is copied from the examples, with the pr reviewers changed to @AdnoC and @michael-siek

I've also included a copy of the auto-assign-issues.yml that was present in all the example repos, as well as moved the semantic-pr-title.yml workflow from ./github/workflow to ./github/workflows (more idiomatic and consistent with other example repos).

Finally, to enable the build/test step to run on ubuntu-latest (which is about 5x faster than windows-latest), I needed to make a few modifications to the selenium integration tests:

• Use environment variables (populated by GitHub actions hosted agents) for webdriver binaries, if available
• Run browsers in headless mode
• Add explicit file:// protocols when translating from file paths to URLs to be compatible with linux-style file paths
• Updated how the WebDriver and Wait properties are queried to remove some noise from failures during driver initialization

The assorted release builds will require the following secrets be added to the repo:

• MY_GITHUB_TOKEN: same as in example repos (used by auto-assign-issues.yml, needs permissions to assign issues to the Axe API team project board)
• CHANGELOG_VERSION: same as in example repos (used by create-release.yml, should be a version number of the conventional-changelog-cli npm package)
• COMMIT_AND_TAG_VERSION_VERSION: new, similar to SEMANTIC_VERSION_VERSION in example repos (used by create-release.yml, should be a version number of the commit-and-tag-version npm package
• ADT_API_RELEASE_NAME: same as in example repos (used by create-release.yml, will be the committer name for release commits)
• ADT_API_RELEASE_EMAIL: same as in example repos (used by create-release.yml, will be the committer email for release commits)
• NUGET_API_KEY: new, should be a NuGet API key with scoped permissions to publish new versions of the 3 specific packages in question. Used by all publish-* workflows.
  • For initial testing of these release workflows, recommend leaving this unset or set to an invalid value for initial dry runs
  • For doing an initial publish, this can be a key that also has permissions to publish new packages, or someone can manually upload the initial versions
• RELEASE_PUBLISHING_GITHUB_TOKEN: new, similar to the GITHUB_TOKEN assumed by the examples' circleci configs. Used by publish-production.yml to create GitHub releases, needs write permissions for releases. Can update this to reuse MY_GITHUB_TOKEN from auto-assign-issues.yml if you want to consolidate.

Once this is merged and working, we should enable corresponding branch protection policies for develop and master

Closes Issue: #4

[dbjorge]

Validation run of pull-request.yml: https://github.com/dbjorge/axe-core-nuget/actions/runs/2922965477

[dbjorge]

Closing this in favor of splitting out build and release into separate PRs. See #35 for the build steps.