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