spike: Cluster API as cluster provisioner

### Problem Statement

When this repository was originally created I was considering [Cluster API](https://github.com/kubernetes-sigs/cluster-api) as the provisioning tool for what is now `Cluster` objects in the environment provisioning portion of this testing framework, but due to concerns of complexity and maturity it was decided to create our own simple cluster provisioners.

Since then cluster-api has matured a lot and is in a v1 release state. At this point it would seem that pivoting to cluster api for provisioning environments would allow us to take advantage of the already existing provisioner implementations for different cloud environments and otherwise reduce our maintenance costs long term while giving us access to all the features of cluster-api and enabling us to help maintain cluster API as part of our use case.

The purpose of this issue is to investigate whether cluster-api would make sense for us as a machinery pivot at this point and create a KEP defining how that would look in practice. Alternatively we may just want to consider the benefits of adding it alongside what we already have.

No files, tests, or code entry points are named. Start by reviewing the linked Cluster API project and the repository's existing cluster provisioners, then document whether adopting it, adding it alongside the current approach, or keeping the existing machinery is appropriate in a KEP.

Written by the indexing model from the issue text.