Add no_code_automation feature category under a new no_code SEG stage

Why is this change being made?

Feature categorization is now required in GitLab codebase when adding new code:

Each Sidekiq worker, Batched Background migrations, controller action, test example or API endpoint must declare a feature_category attribute. This attribute maps each of these to a feature category. This is done for error budgeting, alert routing, and team attribution.

Despite the cross-stage potential, the initial Automation MVC is scoped to the Plan stage only. So considering the feature hierarchy, I'm proposing to place the new category planning_automation under the project_management group until it outgrows from there. This arrangement also reflects the SEG's designated project development group affinity.

I'm also happy to consider other options:

1. Reuse team_planning as the feature category for the time being while implementing the MVC.
2. Create a new SEG group to house the category similar to MobileOps for stronger ownership.

Update:

After some consideration, we believe it's easier to follow the established pattern by placing the SEG feature under its own stage.

Author Checklist

• Provided a concise title for this Merge Request (MR)
• Added a description to this MR explaining the reasons for the proposed change, per say why, not just what
  • Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added, and the content is SAFE
• Assign reviewers for this MR to the correct Directly Responsible Individual/s (DRI)
  • If the DRI for the page/s being updated isn’t immediately clear, then assign it to one of the people listed in the Maintained by section on the page being edited
  • If your manager does not have merge rights, please ask someone to merge it AFTER it has been approved by your manager in #mr-buddies
  • The when to get approval handbook section explains the workflow in more detail
• If the changes affect team members, or warrant an announcement in another way, please consider posting an update in #whats-happening-at-gitlab linking to this MR
  • If this is a change that directly impacts the majority of global team members, it should be a candidate for #company-fyi. Please work with internal communications and check the handbook for examples.

---