Add support for 'include_all_branches' flag when creating repository from a template

[leowebb]

Description

Hi there! I've added support for a flag in the API call here when creating a repository from a template repository. Specifically, I've added just the flag to include all branches when using the template repository.

This is my first contribution, so I was hoping to get access to the hub4j-test-org to generate the necessary test files that I can add with my check-in (along with adding a branch to the template to confirm the behavior here).

I've done testing locally/against repositories within my own account, and it seemed to work well - just need access now to capture the correct snapshots.

Thanks for this awesome SDK!

Before submitting a PR:

• [x] 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.
• [x] 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 .
• [x] Add tests that cover any added or changed code. This generally requires capturing snapshot test data. See CONTRIBUTING.md for details.
• [x] 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.
• [x] Push your changes to a branch other than main. You will create your PR from that branch.

When creating a PR:

• [x] 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.
  • [x] Provide links to relevant documentation on https://docs.github.com/en/rest where possible. If not including links, explain why not.
• [x] 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."
• [x] Enable "Allow edits from maintainers".