Dynamically include job needs to improve query performance

What does this MR do and why?

Our BE team has identified that "name has a worse upper bound on size than the id, and the same job is often a dependency of many other jobs on the app/graphql/queries/pipelines/get_pipeline_details.query.graphql query".

We can't totally drop name as it's used by the Job dependencies view type feature on the graph. We can however defer the data fetch to on-demand and improve initial page performance.

So in short this MR aims to improve performance for the stage view and only fetch needs data for the Job dependencies view. We improve performance by fetching less data for the stage type where needs is not used in this first iteration.

MR acceptance checklist

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

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Stage selection

Job dependencies selection

How to set up and validate locally

1. Visit a pipeline with a CI that has needs keyword
2. Verify on stage view job needs are not fetched
3. Verify on job dependencies view that job needs are fetched
4. Check code to ensure removing this data does not break anything unexpected that might not be covered in test coverage.

Related to #479842