bsdinstall: Encode dists to valid variable names in checksum script

Currently we just strip the .txz of the dist name (and add a status_
prefix) to get the shell variable name for its status, but this doesn't
give a valid result for dists like base-dbg, kernel-dbg and lib32-dbg,
or even kernel.KERNCONF (or, combining the two, kernel.KERNCONF-dbg). As
a result, four things go wrong for such dists:

1. If there is a dot and/or a dash in the name, writing to the variable fails and spits an error out on stderr to the log
2. If there is a dot in the name before any dash, the syntax is always invalid, reading the variable fails, spits an error out on stderr to the log, the result is the empty string and that is interpreted as being 0%
3. If there is a dash in the name before any dot, and there is a dist whose name is the substring up to that first dash, and it has already had its status written to, reading the variable instead reads that dist's variable and so the status of that dist is displayed instead
4. If there is a dash in the name before any dot, and either there is not a dist whose name is the substring up to that first dash or there is such a dist but it has not already had its status written to, reading the varaible instead results in the substring after the first dash, including any additional string expansion syntax that follows (i.e. ${status_kernel-dbg:--11}, the expression used to read the variable, is interpreted as reading status_kernel with a default value of "dbg:--11")

For example, in a default install with base, kernel, kernel-dbg and
lib32, the following sequence of displays happens:

1. base is In Progress, kernel is Pending, kernel-dbg is 0% (what shows for the garbage input "dbg:--11") and lib32 is Pending
2. base is Passed, kernel is In Progress, kernel-dbg is In Progress (since kernel has now had its status written to) and lib32 is Pending
3. base is Passed, kernel is Passed, kernel-dbg is Passed (again, since that is the status of kernel, despite that kernel-dbg is being verified at this point) and lib32 is Pending
4. base is Passed, kernel is Passed, kernel-dbg is Passed and lib32 is In Progress

Fix this with a crude encoding scheme. More special characters can
easily be added if needed in future.

Note that, prior to bsddialog being used (and thus for branches this is
MFC'ed to where dialog is still used), the same problem existed but
displayed slightly differently due to a combination of different default
values and different behaviour for unintended inputs.

Fixes: b70047d41362 ("Add generation of an installation manifest containing SHA256 checksums as ...")
MFC after: 1 week