feat(api): Add project ID-or-slug parser

[gricha]

Add a shared project ID-or-slug parser and DRF field for endpoints that explicitly opt in to accepting either identifier. Existing ProjectField behavior stays slug-only by default, while id_allowed=True can now resolve project IDs or slugs within the current organization and permission context.

This is the foundation PR for the project slug API split. It only introduces the helper, serializer support, and focused tests; endpoint resolver behavior lands in the stacked follow-up PR #117446.

[sentry]

Bug: An invalid project slug raises a generic validation error instead of the intended "Invalid project" error because the specific ValidationError is not caught.
_{Severity: LOW}

Suggested Fix

Modify the except block in ProjectField.to_internal_value to also catch serializers.ValidationError. Inside the handler, raise a new serializers.ValidationError with the intended 'Invalid project' message to ensure consistent error reporting for all invalid project identifiers.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: src/sentry/api/serializers/rest_framework/project.py#L39-L43

Potential issue: The `try...except` block in `ProjectField.to_internal_value` is
intended to catch lookup failures and return a `ValidationError` with the message
"Invalid project". However, when an invalid slug format is used (e.g., containing a
space), the underlying `ProjectIdOrSlugField` raises a `serializers.ValidationError`
before the database lookup occurs. This validation error is not caught by the `except
Project.DoesNotExist` handler, causing a generic slug format error to be returned to the
user instead of the intended, more specific "Invalid project" message.

_{Did we get this right? 👍 / 👎 to inform future reviews.}