MFC r352948-r352951, r353002, r353066, r353070: caroot infrastructure

Infrastructure only -- no plans in place currently to commit any certs to
these branches.

r352948:
[1/3] Initial infrastructure for SSL root bundle in base

This setup will add the trusted certificates from the Mozilla NSS bundle
to base.

This commit includes:
- CAROOT option to opt out of installation of certs
- mtree amendments for final destinations
- infrastructure to fetch/update certs, along with instructions

A follow-up commit will add a certctl(8) utility to give the user control
over trust specifics. Another follow-up commit will actually commit the
initial result of updatecerts.

This work was done primarily by allanjude@, with minor contributions by
myself.

r352949:
[2/3] Add certctl(8)

This is a simple utility to hash all trusted on the system into
/etc/ssl/certs. It also allows the user to blacklist certificates they do
not trust.

This work was done primarily by allanjude@, with minor contributions by
myself.

r352950:
[3/3] etcupdate and mergemaster support for certctl

This commit add support for certctl in mergemaster and etcupdate. Both will
either rehash or prompt for rehash as new certificates are
trusted/blacklisted.

This work was done primarily by allanjude@, with minor contributions by
myself.

r352951:
caroot: add @generated tags to extracted .pem

As is the current trend; while these files are manually curated, they are
still generated. If they end up in a review, it would be helpful to also
take the hint and hide them.

r353002:
Unbreak etcupdate(8) and mergemaster(8) after r352950

r352950 introduced improper case fall-through for shell scripts. Fix it with
a pipe.

r353066:
certctl(8): realpath the file before creating the symlink

Otherwise we end up creating broken relative symlinks in
/etc/ssl/blacklisted.

r353070:
certctl(8): let one blacklist based on hashed filenames

It seems reasonable to allow, for instance:

$ certctl list
# reviews output -- ah, yeah, I don't trust that one
$ certctl blacklist ce5e74ef.0
$ certctl rehash

We can unambiguously determine what cert "ce5e74ef.0" refers to, and we've
described it to them in `certctl list` output -- I see little sense in
forcing another level of filesystem inspection to determien what cert file
this physically corresponds to.

Relnotes: yes

MFC r326276:

various: general adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.

No functional change intended.

MFC r303784, r303785, r305620:

r303784:
etcupdate: directly use diff3(1) instead of merge(1)

During the last attempt to rmeove GNU rcs, 2 blockers were spotted:
We need an ident(1) and etcupdate(8) uses merge(1).

Now nothing should prevent to remove rcs from base

Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D7401

r303785:
always install etcupdate

Now that etcupdate does not depend on rcs anymore there is no need to
conditionnally install it

r305620: (by vangyzen )
etcupdate: preserve the metadata of the destination file

When using diff3 to perform a three-way merge, etcupdate lost the destination
file's metadata. The metadata from the temporary file were used instead.
This was unpleasant for rc.d scripts, which require execute permission.
Use "cat >" to overwrite the destination file's contents while preserving its
metadata.

Reviewed by: bapt
Sponsored by: Dell Technologies
Differential Revision: https://reviews.freebsd.org/D7817

MFC r302674:

META_MODE: Don't require filemon(4) for mergemaster(8)/etcupdate(8)

Approved by: re (gjb)