Draft: Add No one option to Roles allowed to create subgroups group setting

What does this MR do and why?

Group Owners can currently choose whether Owners or Maintainers (and Owners) are allowed to create subgroups in a group, but there is no way to block subgroup creation entirely. This MR adds a No one option to the Roles allowed to create subgroups setting (Settings > General > Permissions and group features, and the Admin area group edit page) and accepts the matching noone value for subgroup_creation_level in the Groups REST API.

When a group is set to No one:

• Nobody can create a subgroup in that group, including group Owners and instance administrators.
• Because the same create_subgroup permission guards those actions, nobody can transfer an existing group into it or import a group into it (direct transfer or file import) either.
• The New subgroup button on the group page and the New subgroup entry in the + (new) menu are hidden for that group.

This mirrors the existing No one option of the Roles allowed to create projects setting (project_creation_level).

Technical details

• lib/gitlab/access.rb: add NO_ONE_SUBGROUP_ACCESS = 2 and the No one / noone entries in subgroup_creation_options and subgroup_creation_string_options. Existing values 0 (Owner) and 1 (Maintainer) are unchanged.
• app/policies/group_policy.rb: create_subgroup_disabled returns true for NO_ONE_SUBGROUP_ACCESS, which prevents :create_subgroup for every user.
• No changes needed in the group settings view, the Admin area group edit view, REST API param validation, the REST/GraphQL group entities, or direct transfer: they all read the option lists from Gitlab::Access dynamically.
• No database migration: namespaces.subgroup_creation_level is already an integer column and no database review is needed.
• Docs: doc/api/groups.md, doc/user/group/subgroups/_index.md.
• Specs: spec/policies/group_policy_spec.rb, spec/requests/api/groups_spec.rb.

References

Closes #619168

Screenshots or screen recordings

Before	After
Two radio options: Owners, Maintainers	Three radio options: No one, Owners, Maintainers

How to set up and validate locally

1. Create a group and open Settings > General > Permissions and group features.

2. Under Roles allowed to create subgroups, select No one and select Save changes.

3. On the group overview page, confirm the New subgroup button is gone. Open /groups/new?parent_id=<group id> and confirm you cannot create a subgroup, even as an Owner or administrator.

4. From another group, go to Settings > General > Advanced > Transfer group and try to transfer it into this group. Confirm the transfer is rejected with a permissions error.

5. REST API:

   curl --request PUT --header "PRIVATE-TOKEN: <token>" "http://gdk.test:3000/api/v4/groups/<group id>?subgroup_creation_level=noone"

   The response includes "subgroup_creation_level": "noone", and POST /api/v4/groups with parent_id=<group id> now returns 403 Forbidden.

6. Switch the setting back to Owners or Maintainers and confirm subgroup creation works again.

MR acceptance checklist

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