Refactor workspaces term config_to_apply to desired_config

MR: Pending

Description

Currently we have two separate terms to refer to the Kubernetes resources which are returned in the Workspaces reconciliation response: desired_config and config_to_apply.

This is confusing, and contrary to the good principle of Ubiquitous Domain Language

We should rename all occurrences of config_to_apply to desired_config, across all codebases (both the gitlab repo and the gitlab-agent repo).

Justifications for going with desired_config:

1. It's generally a more readable name for an object/entity - it ends with a noun, rather than a verbal phrase modifier. This is important when it's used in other naming contexts, e.g. desired_config_generator vs. config_to_apply_generator.
2. desired_config is referenced in the database and GraphQL API, which require long involved processes to deprecate/change.
3. config_to_apply is only referenced in the gitlab-agent protobuf/golang structures. These are easier to deal with (see Implementation Plan).

Acceptance criteria

• All occurrences of config_to_apply/ConfigToApply are replaced with desired_config/DesiredConfig

Implementation plan

• We can add desired_config as an additional field to the gitlab-agent protobuf/golang structures
• We will continue sending the same data in both of the fields
• Then we can eventually deprecate the config_to_apply field according to the documented gitlab-agent deprecation policies.