Omnigres is often portrayed as an advanced application runtime – the one
that embraces data-centric design and control flow.

But if it is an application runtime, how does it fare with today's
methods of deployment? Does it integrate well?

Solution: propose a lightweight integration with Kubernetes

omni_kube allows easily making Kubernetes API calls so that one can
orchestrate resources and get views into what's happening.

This change also required me to add some CA certificate-related
functionality to omni_httpc.

If credentials are coming from within the pod, we're good. But if the
config is coming from somewhere else, we have to supply this to every
API call. That's hardly convenient.

Solution: introduce settings that will dictate defaults

Solution: ensure we do it correctly

1. Ensure we actually pick them up. There could be a `null` in a stat
   record and that would make `is null` succeed. Use `is distrinct from null`
2. Use pod-supplied defaults in the `api()` function if nothing is
   provided.

This conceals problems.

Solution: raise an exception for these

It requires a lot of work to assemble it.

Solution: publish an omnikube image

While doable, it still requires a lot of mundane work to get the data
out.

Solution: provide some common views

This is far away from being complete, but serves as an example of what's
possible.

Currently, even though `omni_kube.api()` is `stable`, it does not
guarantee that it will be only called once per portal (~ statement)

This leads to potential inconsistencies when joining views (information
changes). Some of these are unavoidable if we call different API
endpoints, but it'd be really odd to get one when we're calling the same
API endpoint with the same parameters but something has changed already.

Besides, it slows it down as we make repeat requests

Solution: use omni_var's statement variables
to cache responses

In some cases, all we have is a client certificate and associated
private key.

Solution: add options to support this variation

This also adds functionality to pass the certificate and private key to
omni_httpc.

Solution: add basic support for jobs

This is not very useful.

Solution: change to timestamptz

Solution: add the missing column

Specifically, new options related to certificates.

Solution: document them

Solution: write basic documentation

omni_httpc and omni_httpd are listed twice

Solution: fix that