Use GH action version when version argument not specified

[Jackenmen]

Description

Resolves #3382

There are 2 things going on here:

• addition of .git_archival.txt set with export-subst git attribute so that black can be installed from a git archive, see: https://github.com/pypa/setuptools_scm#git-archives
• update to GH action changing it to use GH action version when the version argument is not specified; this means:
  • when the action's commit is tagged, install Black from PyPI using that tag's name as the pinned version
  • when the action's commit is not tagged, install Black from the action's local directory

A couple of tests:

• Jackenmen/black@22.12.0 - 22.12.0 on my repo is not the real commit of 22.12.0 as then it wouldn't have this feature; however it does allow you to see that the code gets 2022 formatting:
  • https://github.com/Jackenmen/black/actions/runs/4076830464/jobs/7025089166
• Jackenmen/black@e29e12c973d0e294a0a905b1fb4d8f4962bfa408 - the exact same commit that you get with 22.12.0, just confirming that it still correctly detects it as a tagged release in such a case:
  • https://github.com/Jackenmen/black/actions/runs/4076898146/jobs/7025240425
• Jackenmen/black@9a168472de3144674dd7db3c6b514b7e5f5d5c20 - an untagged commit after the fake 22.12.0 tag, this causes the action to install Black from the local source; you can see that this causes it to use 2023 formatting:
  • https://github.com/Jackenmen/black/actions/runs/4076901054/jobs/7025246892
• Jackenmen/black@stable - the exact same commit that you get with 22.12.0, just confirming that it correctly fetches 22.12.0:
  • https://github.com/Jackenmen/black/actions/runs/4077049374/jobs/7025578668

Checklist - did you ...

• Add an entry in CHANGES.md if necessary?
• Add / update tests if necessary?
• Add new / update outdated documentation?

[Jackenmen]

I added the changelog entry. I'm marking this as ready for review though I'd like to point out that I have not updated integration documentation yet because I'm not sure what parts of it you would want me to update if any. Arguably, the version input is still preferable since it allows matching stability policy with a specifier such as ~= 22.0 The main benefit of this change is avoiding confusion when someone specifies only the action version. But perhaps you would want me to change that whole document such that it recommends using the action version for pinning and version input for version ranges. Such a case could require significant document restructuring, so I'm holding off on that for now.