We can be more efficient around how CVO responds to a situation where a CRD is deleted which has a corresponding CR (custom resource) in the cluster and managed by CVO.

Currently we wait for the CRD to show up, but it would be faster to give up on that sync cycle and start over, because an earlier manifest pushed the relevant CR, and someone has since deleted the CR.

As a result CVO would bail more quickly on that task-node, but keep processing other, parallel task-nodes (which might contain the CRD). If none of the parallel task-nodes had the CRD, we'd be into the next sync cycle more quickly, with another set of chances for finding the CRD manifest 

Implementation would be something like:

1. track CRs we've seen so far in the sync cycle
2. when we reconcile a CRD that consumes one of those CRs, let the reconciler know about it.
3. if reconciliation fails on "server does not recognize this resource", fail fast, instead of retrying.