Add builder for updating multiple GHTeam properties.

[rozza-sb]

Description

Currently GHTeam has some single methods on them to update description and privacy properties. There should be a mechanism for not only all properties being updatable (as supported per the GitHub API), but also for multiple properties to be updated atomically.

This change adds support for a new builder that allows for properties to be updated.

Fixes #2218.

Before submitting a PR:

• Changes must not break binary backwards compatibility. If you are unclear on how to make the change you think is needed while maintaining backward compatibility, CONTRIBUTING.md for details.
• Add JavaDocs and other comments explaining the behavior.
• When adding or updating methods that fetch entities, add @link JavaDoc entries to the relevant documentation on https://docs.github.com/en/rest .
• Add tests that cover any added or changed code. This generally requires capturing snapshot test data. See CONTRIBUTING.md for details.
• Run mvn -D enable-ci clean install site "-Dsurefire.argLine=--add-opens java.base/java.net=ALL-UNNAMED" locally. If this command doesn't succeed, your change will not pass CI.
• Push your changes to a branch other than main. You will create your PR from that branch.

When creating a PR:

• Fill in the "Description" above with clear summary of the changes. This includes:
  • If this PR fixes one or more issues, include "Fixes #" lines for each issue.
  • Provide links to relevant documentation on https://docs.github.com/en/rest where possible. If not including links, explain why not.
• All lines of new code should be covered by tests as reported by code coverage. Any lines that are not covered must have PR comments explaining why they cannot be covered. For example, "Reaching this particular exception is hard and is not a particular common scenario."
• Enable "Allow edits from maintainers".

[rozza-sb]

@bitwiseman re: using GHLabel as a base, I agree that this approach would be the more maintainable one going forward. However, we already have GHTeamBuilder using an old approach. Happy to include the new AbstractBuilder as a separate class, but what should it be named in the mean time? Long term there is probably a migration to be had for that type but it will break compatibility as is

As it is this branch has a separate builder for updates, with only wiremocks missing. I'll be working on a commit that does the GHLabelBuilder-like pattern instead.

[rozza-sb]

I've taken a look at the GHLabel pattern, and I think this works quite well as both the create and update endpoints support the same properties. For GHTeam, there are differences between the create and the update endpoints:

1. Create can take maintainers and repo_names whereas update can not
2. Update can take permissions whereas create can not
   a. Admittedly this field is marked as deprecated so we could not support this)
   b. If we do support permissions, different values are supported depending on whether we are creating or updating (admin is supported during update only)

Based on the difference between the create and update it does feel like these should be separate. My current plan is to get the existing change with wiremocks setup, partially due to the separate behaviour, and partially due to not having time before I head abroad to get this new setup in a satisfied state. If we're really against the existing approach, even as a stopgap, we could look at some migration strategy to support the new pattern with differing Creator and Updater requirements without breaking the existing GHTeamBuilder