As we found the hard way, Pacman package names _can_ legally contain a
dash followed by a digit. That has implications on all the code in Git
for Windows that assumes it can deduce the package name from an archive
name simply by stripping any suffix starting with `-<digit>`.

Concretely, the problem we encountered was that the newly-created
`msys2-runtime-3.3` package was first added correctly to Git for
Windows' Pacman repository, i.e. the `git-for-windows.db` file (which
really is a specially-formatted `.tar` archive) now
contained the following entries:

	msys2-runtime-3.3-3.3.6-1/
	msys2-runtime-3.3-3.3.6-1/desc
	msys2-runtime-3.3-devel-3.3.6-1/
	msys2-runtime-3.3-devel-3.3.6-1/desc
	msys2-runtime-3.3.6-4/
	msys2-runtime-3.3.6-4/desc
	msys2-runtime-devel-3.3.6-4/
	msys2-runtime-devel-3.3.6-4/desc

However, when the _next_ package was added (in this instance, Git
Credential Manager), the `sanitize_db` function in `pacman-helper.sh`
(which is run as part of the `quick_add` function in the same file when
Git for Windows' automation deploys Pacman package) misidentified all
the entries starting with `msys2-runtime-3.3` as referring to the
`msys2-runtime` package.

The reason for this is that I originally assumed that `${dir%%-[0-9]*}`
would be a good way to reduce those directory names to the corresponding
package name, i.e. to strip any suffix starting with a dash followed by
a digit.

However, that is not how Pacman works. As can be seen in the
`find_pkgentry` function of `repo-remove`, the correct way is to strip
the last two dash-separated fields: `${dir%-*-*}`, see
https://github.com/git-for-windows/git-sdk-64/blob/HEAD/usr/bin/repo-remove

Note in particular the difference between using the greedy `${...%%...}`
operator and the reluctant `${...%...}` operator (i.e. two vs one `%`
characters).

Let's fix this (better late than never), by using the `${...%-*-*}`
pattern in shell code, and an equivalent in Perl.

Note: When looking for existing directories in `/var/lib/pacman/local/*`
(to determine whether or not a particular Pacman package is installed or
not), it is not _quite_ as trivial because we used a shell pattern
there: `$package-[0-9]*`. In those instances, I introduced a shell
function that iterates through the paths expanded from that shell
pattern and returns the intended one (if any).

Signed-off-by: Johannes Schindelin <[email protected]>