Fix an issue where non-admin tokens cannot use the service account access token resource

• Please check this box if this contribution uses AI-generated content (including content generated by GitLab Duo features) as outlined in the GitLab DCO & CLA. As a benefit of being a GitLab Community Contributor, you can request access to GitLab Duo.

This MR addresses some issues with #6376 (closed) related to the requirement that an admin token is used with the group_service_account_token, which renders it unable to be used on gitlab.com

Unfortunately, two key APIs require authentication either with an admin token, or as the service account itself: the Read API and the Delete Token API. This creates a circular relationship where the token must be active in order to read the token, however the token must be read to determine if it's currently active.

To fix this issue, a couple things were changed:

• The Read API call will now rely on the data stored in state if a 401 Unauthorized is received.
• The Delete API call was changed when using a non-admin token to instead rotate the token and discard the results of the API, meaning the token is "lost" and can't be used. While this leaves a new token "active" in the system, that token will be cleaned up eventually by expiration.

The isCurrentUserAdmin function was moved to the api package to allow its use in the provider package as a result.

These two changes required a slight alteration to the checkDelete function to make sure it's checking the explicit ID and not the name value.

Closes #6376 (closed)