Refactor client/pool into a single struct

[hausdorff]

In the provider and the await package we pass around a discovery client and a client pool so that we can perform and await operations, and get things like Event to produce diagnostic information on the error path.

This has become cumbersome, resulting in a lot of duplicated logic, and I propose to merge these into a single struct that makes these common cases simple. The main benefit is that we write tests that make sure we don't regress the very subtle error handling behavior in the create, delete, and update paths.

---

When we began our journey, the use of kubernetes/client-go was fairly simple. With the introduction of robust CRD support and client-level retry create operations, it has become considerably more complex -- we need to take the disparate error types exposed by the client, and map them into sensible await logic in the await package. For example, in the delete path, we have to:

1. Get a G/V/K-specific client from the discovery client and the client pool.
2. Call .Delete.
3. Call .Watch and wait for a 404 error.

If any of these intermediate steps results in an IsNotFound error, we need to terminate with a successful delete.

To make matters worse, the create and update path have very similar logic.

In the long run this is not maintainable because we have no way to convincingly test that our logic is correct. My proposal is to merge the client pool and the discovery client into a single struct that collapses these intermediate steps into a single .Get, .Watch, etc. Because the client pool and the discovery client are both interfaces, this will make it much easier to encode the desired state machine in tests, making this logic much more verbose.

[hausdorff]

As @lblackstone points out, this may involve upgrading client-go: kubernetes/kubernetes#62913

[hausdorff]

@lblackstone I'm assuming this will happen alongside #344? (I'll proactively put in M20 just ot make sure we don't lose it.)