Token lifecycle (post Gitlab 16.0 changes)

### What problem are you facing?
Since the release of Gitlab 16.0, all forms of tokens have a limited life time and they all expire within 1 year and it's not possible to get any longer period than that. Right now, tokens will expire and just be invalid until you replace the resource. Long living tokens is not something that is desirable and having "short" living tokens that are renewed is a more desirable approach.

Me and a co-worker of mine had meetings with Upbound regarding issues like this among other things. Gitlab has a token rotation API endpoint, but using it is the same as revoke+create, which will yield a new token id. The annotation `external-name` is "immutable" in a sense that updating it is allowed but ignored. So the representative from Upbound came back to us and recommended that managing the tokens (and other time limited resources) as a virtual resources the same way they handle cluster auth for EKS in the AWS provider.
Reference: https://github.com/upbound/provider-aws/blob/main/apis/eks/v1beta1/clusterauth_types.go

When it comes to the importing of existing resources, `external-name` is often used but that can't be used in this case (see prev. paragraph). So they recommended using the relatively new `initProvider` configuration which is a perfect fit for this.
Reference: https://docs.crossplane.io/latest/concepts/managed-resources/#initprovider

Cases:
1. I currently have a token that is about to expire and I need to manually force a replacement to take place to prevent any issues.
2. I want to have short living tokens that automatically renew and where I don't need to resort to any manual actions to maintain.

### How could Crossplane help solve your problem?
Automatically manage tokens over time, supporting smoother transitions of tokens when they need to be renewed.

I was thinking that we could change the implementation of the tokens and keys to a virtual resource that will be able to keep track of both old and new token during a transition period when tokens are being replaced, and update secrets accordingly. It will not have an `external-name` but keep track of the relevant tokens using status.

So the question is if the current implementations of the token controllers should adapt to this new behavior in Gitlab 16.0+
or if a virtual resource (no external resource) manages and owns the current implementations.