Stop favoring REST in the API documentation
### Problem to solve
Originally GitLab had a single API, the REST API. Over time we've added a GraphQL API and a SCIM API. Now we actually favor GraphQL over REST when implementing new features. However, the API documentation still heavily favors REST. For example, much of the documentation refers to the REST API but doesn't say so. This creates a few problems:
- Incorrect guidance for the non-REST APIs.
- Difficulty finding guidance about the non-REST APIs.
- Difficulty identifying gaps in the GraphQL API documentation. (Ideally we want our GraphQL documentation to be as robust as our REST documentation, but right now the differences/gaps aren't clear.)
### Proposal
The documentation should no longer favor REST. Content specific to a certain API should be on that API's documentation page, not a generic page.
- [x] Add "REST" to documentation that only refers generically to "API". See https://gitlab.com/gitlab-org/gitlab/-/merge_requests/64245
- [x] Add link to GraphQL resources, to align with the REST documentation. See https://gitlab.com/gitlab-org/gitlab/-/merge_requests/79267
- [ ] Move "How to use the API" from the [API index page](https://docs.gitlab.com/ee/api/) to a new page: "How to use the REST API". Link to this page from the [REST API section of the index page](https://docs.gitlab.com/ee/api/#rest-api), and at the top of the [REST API resources page](https://docs.gitlab.com/ee/api/api_resources.html).
- [ ] Create a page for "How to use the GraphQL API" (similar to the REST page). Link to this page from the [REST API section of the index page](https://docs.gitlab.com/ee/api/#graphql-api), and at the top of the [GraphQL API resources page](https://docs.gitlab.com/ee/api/graphql/reference/).
epic