Replace 'basename' with substring processing of $0

Dear Maintainers.

Thank you for providing an opportunity to contribute.

Please, allow me to elaborate on this merge request.

SYNOPSIS

In applicable shell scripts, assign PROGNAME variable using substring
processing of the expanded special parameter 0, instead of creating a
subshell environment, which involves many system and library calls,
including but not limited to fork(), exec() and stat(), to execute
the 'basename' utility.

DESCRIPTION

'deb-reversion', 'wnpp-alert' and 'wnpp-check' already do this. If
anything, the assignment of PROGNAME shall be uniform and consistent
across all applicable shell scripts included in the package.

The argument for replacement was provided in merge proposal #425107
on Launchpad[1]. It basically boils down to the following analogy:

Two screws that hold the handle of your entrance door have loosened up
a bit. You decide to tighten them today. You order a new toolbox from
Home Depot, despite already owning a screwdriver that's perfectly
fit for these specific screws. You call them, make your order and
wait until it arrives. Once your new toolbox arrives, you become
all happy and excited. However, the moment you open it, you realize
that it has too many tools and a variety of screwdrivers. Now,
you pick them up one by one and check whether this particular one
in your hands fits. By the time you find the right one, an hour or
two have passed. You carry on to actually fixing the door...

Now, the difference in our scripts isn't as dramatic and significant
as in the above illustrative analogy. While it is true that the
shell was specifically designed to provide an interface for a user
to invoke utilities and communicate with the operating system, it
doesn't mean basic programming practices and efficient code should be
neglected in shell scripts. There's no tangible benefit in calling
external programs and utilities, if the shell's built-in commands
and constructs allow for producing identical output.

Furthermore, the backquoted form of command substitution should be
avoided and "is not recommended" by POSIX. This is another (however
minor) reason to replace them with parameter expansions.

Note that quoting the expansion is not required on assignment. Special
parameter 0 will arrive intact, with fields not split and pattern
matching characters not expanded, provided that an invoking user
protects them before invocation (as they should), e.g. `'./path
to*some\nscript'`. They are, however, required on retrieval, e.g. `echo
"$PROGNAME"`.

For what it is worth, my personal preference is that no variable in a
script should be given a name in all caps irregardless of whether it
contains a constant or a variable value, except when it is exported
to child processes. This is line with POSIX. Even though environment
variables are mostly set in stone during login or invocation, they
may change throughout the session. Restricting variables to only
lowercase letters ensures that no clashes occur between environment
and application-defined variables.

Also, the name 'PROGNAME' doesn't fit in shell scripts. For this
reason, I prefer the name "script", e.g. `script=${0##*/}`, though
imposing such conventions is not my intention whatsoever.

PS

I hope I have captured everything that needs elaboration. If you find
that I did not, please share your questions, ideas and suggestions.

Thank you.

[1]https://code.launchpad.net/~kbar/ubuntu/+source/devscripts/+git/devscripts-1/+merge/425107