Separate tabs for project and shared agents

What does this MR do and why?

This MR updates the agents' page to separate project agents from the shared agents. This will allow us to use proper pagination for the project agents in the future and reduce the complexity of the query.

The page is doing 3 GrpahQl requests:

• project agents
• shared agents
• agent configurations (this is needed to populate the agent configuration column with the correct link to the config file)

We now have 2 tabs. If neither the project nor shared agents are available, we'll render an empty state and not show the tabs. If any of the agent queries have data or errors we'll show the corresponding tab.

We have the functionality of updating the agent query cache with the newly created agent. This is now modified to update only project agents and move to the first tab so that the user can verify the update.

✨ GitLab DUO summary ✨

This merge request introduces significant changes to the GitLab Cluster Agents feature. The main updates include:

1. Separating project agents and shared agents into different tabs, allowing for better organization and visibility.
2. Improving the data fetching and display logic for both project and shared agents.
3. Updating the UI components to accommodate the new tab structure and handle loading states more effectively.
4. Modifying the GraphQL queries and cache updates to support the new agent structure and count information.
5. Enhancing error handling and empty state displays for different scenarios.
6. Updating the tests to reflect the new component structure and functionality.

These changes aim to improve the user experience when managing cluster agents, providing a clearer distinction between project-specific and shared agents, and offering better performance and error handling.

References

Please include cross links to any resources that are relevant to this MR. This will give reviewers and future readers helpful context to give an efficient review of the changes introduced.

• Improve UX of registering a GitLab Agent (#349809 - closed)
• ✨ Beautifying our UI (17.7-17.8) ✨ (#506374 - closed)

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.

Before	After

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

Enable KAS on your GDK (steps 1-2 from the guide).

To create a project agent:

1. Visit Project -> Operate -> Kubernetes clusters page
2. Select Connect a cluster button and follow the instructions in the modal:
   • fill in a name for a new agent
   • select Create and register
3. Verify the created agent shown up in the Project agents section.

To create a shared agent:

1. Visit another Project -> perate -> Kubernetes clusters page and create an agent similarly to the previous point.
2. Create a configuration file for the agent at .gitlab/agents/<your-agent-name>/config.yaml
3. Add the following configuration to the agent:

   ci_access:
     projects:
     - id: <your-first-project-id>

4. You'll need to connect an agent in order to make it visible in the shared section:
   Follow points 3-8 from the guide and then the Deploy the GitLab Agent (agentk) with k3d section to create a local cluster and connect your agent with the cluster.

Related to #349809 (closed) and #506374 (closed)