RFR: 8308961: Automatically find configuration matching name of checked of branch [v2]

[Erik Helin]

> Hi all,
> 
> please review this smaller patch to the build system. This patch changes what the build system will do when there are multiple configurations available and none has been selected (neither via `CONF` nor via `SPEC`). Instead of printing an error message (current behavior) the build system will instead check if the name of any configuration exactly matches the name of the checked out Git branch. If so, then that configuration will be built.
> 
> The rationale for this change is that many developers (including me) use branches to work on multiple things concurrently. Having (at least) one configuration per branch, named after the branch, is a very natural model then for setting up one's build configurations. Having the build configuration corresponding to the checked out Git branch built automatically is then very convenient (instead of typing `make CONF=$(git branch --show-current)` every time).
> 
> A couple of design considerations:
> - why use `$$(shell command -v git 2>/dev/null)` instead of `$$(GIT)` from autoconf? Because we don't have a `spec.gmk` available because we haven't chosen a configuration yet, so we don't have `$$(GIT)`.
> - why use `git rev-parse --abbrev-ref HEAD` instead of `git branch --show-current`? Because `git rev-parse --abbrev-ref` has been around since [2009](https://github.com/git/git/commit/a45d34691ea624e93863e95706eeb1b1909304f3) and `git branch --show-current` was introduced in Git 2.22 in 2019 (plus that `rev-parse --abbrev-ref` works with a detached `HEAD`). `git rev-parse --is-inside-work-tree` is from [2007](https://github.com/git/git/commit/892c41b98ae2e6baf3aa13901cb10db9ac67d2f3), but I think requiring a Git installation more recent than 2009 should be ok.
> - why match the branch name exactly instead of a looser matching? This could be beneficial if branches are named e.g. `$(git branch --show-current)-fastdebug`, but I wanted to start out with something strict and then the matching can be made looser if needed.
> - is this backwards compatible? Yes, at least I think so. Previously the build system would return an error but now it might build a configuration, that seems compatible. The patch does not interfere at all with the code paths where `CONF` or `SPEC` has been set.
> 
> ### Testing
> - [x] Tested locally on macOS/aarch64 and Linux/x64 with and without configurations matching the named Git branch.
> - [x] Tested locally on macOS/aarch64 and Linux/x64 without a Git client.
> - [x] Tested locally on macOS/aarch64 a...

Erik Helin has updated the pull request incrementally with one additional commit since the last revision:

  Fuzzier matching

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14202/files
  - new: https://git.openjdk.org/jdk/pull/14202/files/b233d60f..db7c8b6a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14202&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14202&range=00-01

  Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14202.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14202/head:pull/14202

PR: https://git.openjdk.org/jdk/pull/14202