[Epic] A lot of projects cause high latency on with the projects endpoint

### Problem
In the Sentry frontend, our application works by loading in _every single project_ the organization has.

For each project, we also load in _a lot_ of fields. This API call does not take advantage of expand/collapse fields, other than latestDeploys
https://github.com/getsentry/sentry/blob/d3b1c9447d2eb269d6ccddbecabd7f8c276abee6/src/sentry/api/endpoints/organization_projects.py#L141

This means that orgs with lots of projects run into extremely slow app bootstrap times.

Example Trace: https://sentry.sentry.io/performance/sentry:31cf1253bfb14e3594dee7ded2b2cc74/

The long term solution here is to de-couple the frontend from requiring all projects, and querying individual projects selectively when needed. This is a massive undertaking, as we're talking about a decade+ of code that assumes that it has all projects loaded in.

Until then, we can take this effort on in two ways:

1. Improve the latency of the overall data retrieved on the backend
2. Add more collapse fields to the project api request, allowing us to fetch less data, or improve our caching capability.

List of tasks for Improving the latency on the backend:
```[tasklist]
### Tasks
- [ ] Improve feature flag call latency by using sets instead of lists for hardcoded orgs
- [ ] https://github.com/getsentry/sentry/issues/65943
- [ ] https://github.com/getsentry/sentry/issues/65942
- [ ] https://github.com/getsentry/sentry/issues/65946
- [ ] https://github.com/getsentry/sentry/issues/65947
```

List of tasks for adding more collapse fields on the frontend:

```[tasklist]
### Tasks
- [ ] Collapse as many feature flags as possible, if not all of them
- [ ] Collapse `eventProcessing`, and figure out how to display this component without the field existing on the project cache.
```

I'd like to make a task lisk for removing dependency of having all projects loaded, but that may be too ambitious at this point.

```[tasklist]
### Tasks
- [ ] https://github.com/getsentry/sentry/issues/65949
```