fix: read the service account email from the service accounts API

The group and project service account resources read from GET /users/:id. This endpoint sends the email field only to instance administrators. Most users manage their service accounts with a group Owner token. For these users, the endpoint does not send the email field. The provider then wrote an empty value to the state. Each subsequent plan showed this difference: email = "" -> "user@example.com".

The two data sources had the same problem, and could not show the email field. The resources now read from GET /groups/:id/service_accounts and GET /projects/:id/service_accounts. These endpoints send the email field to group Owners and to project Owners. This change also adds the email attribute to the two data sources.

GitLab has no endpoint that sends one service account. Thus the provider reads the list of service accounts. The gitlab.Scan2 function reads each page and stops at the first match. The code used this method before commit 3239dc99. The fix for gitlab_group_service_account_access_token in commit 9253647d used the same method.

This change also makes the username attribute Computed on the two resources. GitLab makes a username if the user does not give one. The provider sent this username to Terraform, but the configuration value was null. Terraform then showed this error: "was null, but now cty.StringVal(...)". The project resource now uses UseNonNullStateForUnknown. The provider does not use a null prior state as the planned value.

The gitlab_instance_service_account resource keeps the users API. Only administrators can manage instance service accounts. Also, its list endpoint does not send the email field.

Closes #6862 (closed), #6872 (closed), #6871 (closed)