Moved to common_types.go

I wonder if we should actually prefix the types/seasons with the API kind they go with so that it is more clear, and less likely that we'll accidentally use a type that was intended for another API.

I was thinking we could go that way too, but I ended up going the route of sharing the ones that are common. Not a strong preference at all though and I'm happy to do it the other way, too. Your suggestion also makes more sense if we ever changed the value of one and didn't want it to propagate to every API that uses it.

I've updated this particular field so it's not generic, but to more specifically address your comment would you like something like this?

	// Condition Types
	ClusterExtensionRevisionTypeAvailable = "Available"
	ClusterExtensionRevisionTypeSucceeded = "Succeeded"

	// Condition Reasons
	ClusterExtensionRevisionReasonObjectAvailable           = "Available"
	ClusterExtensionRevisionReasonReconcileFailure          = "ReconcileFailure"

My suggestion is:

<RootKind>Type<Type> = "<Type>"
<RootKind>Reason<Reason> = "<Reason>"

I think we even have a unit test that enforces that the const name suffix matches its string value (and it may have to be adjusted to account for the Kind prefix)

My main motivation is less about how changing one might accidentally mean changing others, and more about making it less likely that we accidentally use a type or reason in one API when it was never meant to be used for that API in the first place.

So if we have TypeAvailable and it is meant for ClusterExtensionRevision only, it would be pretty easy to imagine another PR that comes in later that changes the ClusterExtension status to use TypeAvailable and we miss that in a review.

It would be easier to catch in a review (and less likely to be committed in the first place) if it was called ClusterExtensionRevisionTypeAvailable.

And if we ever needed to actually have "Available" as a type for ClusterExtension, that would be fine: we'd add ClusterExtensionTypeAvailable = "Available".

Super quick glance and I only see test code for type/reason registration in the ClusterExtension unit tests? If that's true, perhaps we should capture another TODO Jira issue to expand that unit test to cover types and reasons for all of our APIs.

I know this PR faithfully creates constants for everything that we're actually using, and it is almost the point of this PR to centralize this and make it plainly obvious what our true surface is. So this is what I expect of this PR! :)

So now that we see this, here are meta questions meant for all of us:

1. do we need this many reasons?
2. are these the "right" reasons? (for example, I added "ReconcileFailure" on a whim just to hack the status plumbing together)

I think we should stick with the pattern Reason<Reason> = "<Reason>"

ReasonAvailable is already set in clustercatalog_types.go, which was why initially I moved that one to the common_types.go to share it with CER. So we either need to combine them like I did before or have another distinct name, though it doesn't have to be ReasonObjectAvailable, of course 😃

...although following your recommendation here, this will resolve itself if I name it ClusterExtensionRevisionReasonAvailable.