Proposal on improvements for provider-template

## What are current challenges for using provider-template

I spent some time to dogfooding the provider-template with the current setup, and there are a few points I would like to bring up and improve them.

* A few manual steps are required to make it works. For example, in order to initialize the generated repository, you will not only need to run Makefile to change some predefined names in one or more places. For example, `go.mod`, `Makefile` itself and the `apis` folder for changing repository name.

* Instead of maintaining ready-to-work example provider, it would be reasonable to make it templated through go-templating or similar approach already introduced under `hack/helpers`. I believe the concept of ready-to-work provider is to show case the provider-template trying to demonstrate but importantly it's to make it friendly and extendable for anyone who interested in developing their own provider for Crossplane. Ideally, we can extent what exists in `hack/heplers`, and let it be able to bootstrap the whole go code like `go.mod`, `Makefile`, `apis`, `internal`, `cmd` and so on kind of like `upjet` is doing. By doing this, we're able to make sure whoever using the template can always bootstrap a clean and ready-to-go provider with bare minimal setup.

* Currently, `provider-template` is targeting Crossplane v1, but in the foreseeable future, we might need to support v2 for namespaced resources.

## Proposed improvements

* Extend `hack/helpers` to be able to support not only for an API GVK, but also for other things like `cmd`, `go.mod` and maybe `Makefile`. So we can skip some manual steps, and let the tool do the job
* Explorer an implementation for Crossplane v2, the `provider-template` after this should be able to generate a provider for either v1 or v2.