Log Message:
shells/bosh: Update to 20210421

Changelog from AN-2021-01-05:
- Bourne Shell: When we introduced ${.sh.path} in February 2020, we did
  use the "new" and POSIX-only function realpath() that is not present
  on e.g. Ultrix. We now use abspath() from libschily if realpath() is
  missing.

  Note that abspath() is better than realpath(), as it supports path
  names longer than PATH_MAX, but since ${.sh.path} is only used to
  return the absolute pathname for the current shell binary, this is
  not a problem and on the other side, we can avoid linking against
  libschily this way, so shell scripting with lazy linking is faster
  since less libraries need to be linked at startup.

Changelog from AN-2021-04-21:
- Bourne Shell: gmatch.c: The new version no longer aborts with an
  illegal multi byte sequence as "no match". As a result, the "*"
  now again matches any filename - even if the filename contains an
  illegal multi-byte sequence. This is a problem that did not exist
  on the original Bourne Shell from Solaris that used gmatch() from
  the AT&T libgen, but since we added our private portable gmatch.c.
  to get better portability.

  Thanks to Stephane Chazelas for reporting the problem related to
  multi-byte to wide character conversion and illegal multi byte
  sequences in the case statement and filesystem globbing.

- Bourne Shell: word.c::readwc() no longer uses prwc() but rather
  a loop on the original multi-byte stream to print the "set -v"
  output. This permits to output the original input data in any
  case instead of stumbling over illegal multi-byte sequences.

  Thanks to Stephane Chazelas for reporting the general problem
  with input byte sequences that cause an EILSEQ error.

- Bourne Shell: struct fileblk now remembers lastwc and the related
  input string as fileblk->mbs[] in order to avoid incorrect
  conversions via wctomb() in case that the input wide char was a
  result from an EILSEQ conversion and thus has no related multi
  byte string.

  An important visible result of that change is that input read
  by the builtin command read(1) correctly forwards input that
  caused an EILSEQ error.

  It could not be verified whether this covers all possible similar
  cases, but it is at least very close to a completely correct
  solution.

  Thanks to Stephane Chazelas for reporting the general problem
  with input byte sequences that cause an EILSEQ error.

- Bourne Shell: xec.c: Cstyle changes

- Bourne Shell: the Copyright messages now mention 2021