custom readiness

[davidmdm]

This PR adds in-cluster custom resource readiness definitions for yoke.

When yoke applies resources you can use the --wait=duration flag to have yoke wait for the revision to be ready.
In the ATC, the reconciler is requeued until all child resources are ready so that we can mark the Airway instance resource or generic flight resource as "Ready".

However yoke only knows about standard workloads and core resources: pods, replicasets, deployments, daemonsets, statefulsets, namespaces, customresourcedefintions, and so on.

If you're flight deploys a custom third party resource, yoke has no way of knowing what the ready condition is for that resource.

Therefore we are introducing configmaps to extend custom resource readiness.
These configmaps are identified by the label: resource.yoke.cd/readiness in (lua,conditions).

The lua readiness configmap kind expects lua scripts as the data values with keys being the groupkind string.
This allows you to write custom logic to define what readiness means for a given resource.

The conditions is a whitespace separated list of fields with the status conitions we require to be true for the resource to be considered Ready.

ie:

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-readiness-lua
  labels:
    resource.yoke.cd/readiness: lua
data:
  CustomKind.custom.group: |
    return function(resource)
      return resource.status.deployed > 0 and #resource.status.errors == 0
    end
  *.other.group: |
    ... more lua ...
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-readiness-conditions
  labels:
    resource.yoke.cd/readiness: conditions
data:
  CustomKind.custom.group: Accepted Ready
  *.other.group: Programmed Established