Discussion: split `rules` into `branch_rules`, `push_rules` etc. in ruleset resources

Our ruleset resources currently have a `rules` Set just the GitHub API accepts it. This requires us to write custom validation logic for rules which are allowed only with a specific `target`.
To make validations and UX simpler, I'm suggesting to split the `rules` attribute into something like `branch_rules`, `tag_rules`, `push_rules` etc.

This would remove the need for us to validate which rule is allowed with with `target` and it would be clearer for our users as well that rules relate to targets.

> On the shoulders of https://github.com/integrations/terraform-provider-github/pull/3110/changes#r2827158611: What if we split the rules into separate lists based on which target they work with?

That would enable us to remove the rules validation for "is this target allowed to set this rule" and replace it with simpler built-in validators.
It would make the UX for our users nicer since they don't have to trial-and-error the rules.

_Originally posted by @deiga in https://github.com/integrations/terraform-provider-github/pull/3110#discussion_r2827187209_

Start by reviewing the ruleset resources, their current `rules` Set, and the target-specific validation discussed in pull request #3110. Determine the target-based attribute design and validation behavior before changing the schema; done means the API remains supported while invalid rule-target combinations are rejected clearly.

Written by the indexing model from the issue text.