Provider upgrade tests

[hasheddan]

Crossplane supports upgrading providers from one version to another. This causes a transition of control of installed CRDs from one ProviderRevision to the next. In order for the new ProviderRevision to become healthy, it must be able to gain control of any existing CRDs that it will reconcile, create any missing CRDs that it installs, and successfully start its controller Pod.

All community supported providers should be periodically tested (nightly is fine at first) that at least the upgrade from the most recent stable version to the most recent build from the development branch is successful. A new GH workflow should be added that:

1. Sets up a kind cluster
2. Installs Crossplane (probably latest development build)
3. Installs the latest stable version of a provider
4. Waits for provider to become healthy
5. Updates to the latest development build of the provider
6. Waits for the development version to become healthy

It may make sense to build a GH action for this so that it can be re-used as a single step in a workflow. This can be accomplished with a composite action, similar to the one that we use for the Crossplane CLI. The code that we use to install / upgrade / wait for a Provider to become healthy can live in this repo (crossplane/test) and we can run it by cloning the repo with the checkout action, and then just running go test ....

/cc @rahulgrover99

[hasheddan]

Fixed by #10, thanks @rahulgrover99!