shar: add a deprecation notice

[kevans]

Summary

The shar(1) program is simple, but the fundamental idea of a sh archive
is risky at best and one that we probably shouldn't be promoting as
prominently as a program in $PATH and a manpage. Let's deprecate and
remove it, since the same functionality can easily be found in
tar(1) instead.

MFC after: 3 days

[delphij]

I like the change; maybe worth mentioning why we are deprecating it?

usr.bin/shar/shar.1

34–43

The rendered result would be something like this:

DEPRECATION NOTICE
     shar is obsolete and may not be present in FreeBSD 15 and later.

     Because shell archives are both data and code and usually interpreted by
     sh(1), they can be easily trojan horsed and poses a significant security
     risk, similar to the widely discouraged practice of piping commands from
     curl(1) directly into a shell.  For existing shar archives, we highly
     recommend inspecting them with

           egrep -av '^[X#]'

     before executing.

     Th functionality provided by shar can still be found in tar(1) if needed.

[kevans]

Incorporate recommendation of highlighting why we want to deprecate it.

Primarily left out is the recommendation on how to inspect them; that
information is repeated at the bottom, and I think it makes more sense to keep
DEPRECATION NOTICE more strictly focused on what we're doing.

[brooks]

I would definitely like it to be harder to create shar files. They may have served a purpose in the 80s, but now they are absurd.

[imp]

I'll add, though, that there's no shar format. In the early days of net-news/usenet, there
were a dozen or so shar producing things that produced a crazy variety of encodings to
survive the slings and arrows of 1980s dialup internet that wasn't 8-bit or even 7-bit
friendly at times (though UUCP used for news transport coped well, many mailing lists
and mailers were more picky).

So this means the above recipe is incomplete, but likely sufficient for nearly all shar
archives that aren't hostile. It's detailed enough for this context, and more about
where it falls short (except maybe adding "or similar" in the right spot) wouldn't
be worth it, imho. It's also old advice, so likely not worth tweaking.

This doesn't affect the ability for us to extract shar-balls from BZ if we need to
do that still. We should have long ago mandated git format-patch for all submissions
anyway, though the 10k bug backlog means we're stuck with whatever is out there.
Rewriting any old advice to submit shar-balls is part of the deprecation process.

Tar is mildly more functional here and can be an easy to adapt replacement
with minimal changes to existing scripts (and a shar wrapper is trivial to write).

tl;dr: we should have done this long ago.

usr.bin/shar/shar.1

34–43

s/The functionality provided by shar.../The tar(1) command produces shar encodings of file if needed/
maybe?

[kevans]

One last wording tweak: be more direct about what tar(1) provides