Expose provisioned_by_project_id in admin users API

What does this MR do and why?

Adds provisioned_by_project_id to the UserWithAdmin entity so admins can see which project a service account was created in.

There's currently no way to get this from the API. The only option is a rails console lookup:

User.find(<user_id>).user_detail.provisioned_by_project_id

which means Support has to file a production access request just to answer "which project does this service account belong to?".

I put it in CE and left it ungated. provisioned_by_group_id sits in EE behind group_saml because SAML provisioning is what sets it, but provisioned_by_project_id is only ever set for project-scoped service accounts, and those are available on all tiers now (#540775).

I went with exposing the raw ID only, to match the behaviour of provisioned_by_group_id.

Also updated the four admin response examples in doc/api/users.md.

References

• Internal Example of Support needing to do a rails console request to find where a service account was created: https://gitlab.com/gitlab-com/support/internal-requests/-/work_items/27071

How to set up and validate locally

1. Create a project-scoped service account:

   curl --request POST --header "PRIVATE-TOKEN: <owner_token>" \
     "http://localhost:3000/api/v4/projects/<project_id>/service_accounts"

2. GET /api/v4/users/<user_id> as an admin on the service account and check provisioned_by_project_id matches the project.
3. GET /api/v4/users/<user_id> as an admin on any regular user and check it comes back null.
4. GET /api/v4/users/<user_id> as a non-admin on the service account and check the field is absent.
5. GET /api/v4/users/<user_id> as a non-admin on any regular user and check the field is absent`.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.