Add basic support for activeGate auth token

[luhi-DT]

Description

This change introduces the activeGate auth token support. It basically adds the ability to create an auth token within the operator if the feature flag feature.dynatrace.com/enable-activegate-authtoken: "true" is set on the DynaKube.
This is the first PR of the whole activeGate auth token support feature, as token rotation will be included at a later stage.

How can this be tested?

1. Create an API Token with the correct permission activeGateTokenManagement.create
2. Create a Dynakube that also creates an activeGate and add feature.dynatrace.com/enable-activegate-authtoken: "true" to it
3. check if the activeGate gets the correct secret mounted and check the logs of the activeGate if it uses the created auth Token

Checklist

• Unit tests have been updated/added
• PR is labeled accordingly

[0sewa0]

My reviews aside, I reeally don't like the idea of having both a status field based on the scopes and a feature-flag to turn the thing on-off.
This means we have 2 different knobs that kinda do the same thing. (and rather confusing)
The user can opt out 2 different ways, by not having the scopes for their token OR adding the feature-flag.
(I guess) most users still have to opt-in, because they need to update the tokens.

I know the reason for having this is so that the Deployment Page just creates a token with the correct scopes by default and the authToken will be used unless explicitly turned off.
Couldn't we have just 1 feature flag to turn the thing on and the Deployment page could add that annotation to the dynakube by default instead ?

In this case, if turned on and scopes are not correct, we complain (like with the automatic kubernetes monitoring registration).
(And in the future when having this new scope is the norm, we could flip the default value of the feature-flag to true, doing so the Deployment page is safe as even if they still set the feature-flag, because it will only be redundant)

changes were made