Add explicit share_with_community_members input to fork_group

Problem

The fork_group module cannot create a fresh nested group chain in a single apply.

The gitlab_group_share_group.community_members resource used a count derived from a runtime value:

count = var.parent_group_id == data.gitlab_group.top_level_group.id ? 1 : 0

When a chain of new groups is created in one apply (for example gitlab-com/gl-infra then gl-infra/gitlab-dedicated then gitlab-dedicated/customer-tools), each new group's ID is only known after apply. That unknown ID is passed as parent_group_id to the next module down the chain. OpenTofu cannot evaluate a count that depends on an unknown value, so the plan fails.

The practical effect: nested groups have to be added one per merge request, each merged and applied before the next can be created. Recent history shows this pattern, for example gitlab-org/embody-team and its child experimental-observability landed as separate changes.

This surfaced while preparing a community fork for gitlab-com/gl-infra/gitlab-dedicated/customer-tools/terraform-outbound-proxy, which needs three new nested groups that do not exist yet.

Proposed approach

Replace the runtime comparison with an explicit boolean input.

• Add share_with_community_members (bool, default false) to the fork_group module.
• count now reads var.share_with_community_members ? 1 : 0, which is known at plan time.
• Set share_with_community_members = true on the six direct children of the top-level gitlab-community group (components, gitlab-com, gitlab-community, gitlab-da, gitlab-org, security-products).
• Remove the now-unused module-local data "gitlab_group" "top_level_group".

The sharing decision is now declared at the call site instead of inferred from the parent ID. Because the count no longer depends on parent_group_id, a full nested chain can be created in one apply.

Behavior is unchanged for existing forks

The share is created for exactly the same six top-level groups as before. Nested subgroups inherit the share and do not get their own, unchanged. The plan for existing forks should show no changes to any gitlab_group_share_group resource.

Smaller alternative considered

A smaller change is possible without touching any caller: derive the count from the upstream path depth.

count = length(split("/", var.upstream_path)) == 1 ? 1 : 0

A top-level fork always has a single-segment upstream_path, verified across all current module calls, so this produces identical behavior with a module-only diff. It was not chosen because it couples the sharing decision to the fork-naming convention rather than declaring it explicitly. Happy to switch to this if reviewers prefer the smaller diff.

Validation steps

CI runs fmt, validate, and plan on tofu/** changes.

To validate manually:

1. Run a plan against the current state on this branch.
2. Confirm the plan shows no changes to any existing gitlab_group_share_group.community_members resource (the six top-level groups keep their share; nested groups still have none).
3. On a follow-up branch that adds a fresh nested group chain, confirm the plan succeeds instead of failing on an unknown count value. This is the behavior the change enables.

Context

Related to the onboarding request that surfaced the need: gitlab-community/community-members/onboarding#5280.