XXX: re-introduce a similar check when we allow optional filtering,
if filtering is chosen.

CA certificates are used to secure TLS connections to backends. Since
a CA chain may be required, they may encompass more than one
certificate. For haproxy they are stored as concatenations of PEM-
encoded X509 certificates.

Currently CA certificates are obtained from the contents of Secrets.
Although they are actually not secret, this appears to be the way
they are commonly provisioned in k8s deployments. The code is
implemented in part to facilitate other k8s types in the future,
if so desired.

For convenience it is also possible to specify the pre-installed
CA certificate bundle provided by the base image, since this is
a common way to include well-known CAs that may be needed in a
chain. But it's a better practice to specifically provide all
CA certificates required for a chain by k8s means (i.e. in Secrets).

The k8s client now watches all Secrets without filtering, since
there is no attribute commonly used to specifically identify
Secrets containing CA certificates.

This adds the package pkg/cacrt, the REST "bndls" endpoint and
handler, and the CLI options caBase and distroCABundle.

XXX: add the option to filter for a label that identifies Secrets
with CA certificates. Such a label will have to be set in the k8s
deployment, but then we can go back to filtering Secrets.

XXX: the REST handler currently does not allow GET or HEAD requests.
These will be added to work the same way GET and HEAD requests work
for the pem endpoint (i.e. for TLS offload certificates).

Trying to make go get for this repo work has been a dependency
nightmare; if there's a way for it to work at all (and I haven't had
proof that there is), it's far more effort and pain than it's worth.

Newer versions of the k8s libs have dependencies that evidently
require Go 1.16. Apart from the complications that may arise from
migrating the language version:

- Go 1.16 is currently not provided in the package repos for distros
such as Debian.

- go get -d under Go 1.16 downloads the source to directories under
$GOPATH/pkg/mod/ with the version in the directory name. This can cause
scripts running go get to break, since they have to get the version
name exactly right. Source code download is necessary for packages
that cannot be built with go build alone (for example if they require
a make command).

- go get -d under Go 1.16 appparently doesn't download go.mod for
some reason, which may make a build impossible.

On the other hand, git clone && make install for this repo just
works.

At least we're upgrading to a newer 0.16.x micro version than was
previously supported.