Improve release management

[ashish-amarnath]

/kind feature

Describe the solution you'd like
[A clear and concise description of what you want to happen.]
As a CAPA user, I would like to be able to answer questions like:

• What commit was a controller image tag built at?
• What manifest versions are compatible with which controller image tags

Coupling the release version and the image tag will help in user troubleshooting and ensuring compatibility.

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Environment:

• Cluster-api-provider-aws version:
• Kubernetes version: (use kubectl version):
• OS (e.g. from /etc/os-release):

[randomvariable]

Concretely, the image tag for v0.1.1 release is actually 0.0.5, which is confusing to consumers of Cluster API Provider AWS.

Although this was removed to allow the semi-automated release process to work properly, some of the intent in #580 was as follows:

• Moving versioning into .bazelrc, meant a commit could be checked out and it would be clear which release artifacts were still valid. The idea being that for a release, a developer would do the following:

1. Tag release
2. CI system picks up tag and runs release pipeline
3. Bump version in .bazelrc to next release and commit

As far as the controller goes, #433 should be repeated for the manager, and optionally consider pushing additional image tags related to commit id and other version specific metadata.

I have updated the release at https://github.com/kubernetes-sigs/cluster-api-provider-aws/releases/tag/v0.1.1 to explicitly state the controller image for now.

[detiber]

/milestone v1alpha1