Combine many dependabot PRs into one

[rnorth]

4135 explored a scripted approach (running client side) of combining multiple PRs into one.

The motivation is that the sheer volume of dependabot PRs creates a weekly multi-hour merge chore, as well as obscuring real PRs by real people - both of which are terrible.

https://github.com/dependabot/dependabot-core/issues/1190 looks like it won't happen any time soon.

https://www.hrvey.com/blog/combine-dependabot-prs looks very promising and I think we should give it a try instead of my previous script attempt. I'd like to verify:

• that, as seen in #4135, we can have the release notes updates automatically. We'd need to:
  • enable merge commits in this repo, and make sure we use them when merging the combined PR
  • (I think) update our release-drafter workflow triggers, so that pull request events trigger release drafter. Even if not required, we should probably do that anyway.
• that merge conflicts are not too big a problem. We'll likely seem them occurring with changes in adjacent lines in build.gradle files, which may or may not be a nuisance.
  • if merge conflicts are a problem, I have written a dirt-simple git merge driver script which seems to work well enough for build.gradle files - perhaps we could explore using this.

[rnorth]

Draft observations from #4176:

• Merge conflicts are a pain, because it's necessary to run the workflow, see it fail, and work out which PR to add a nocombine label to. We could improve this by:
  • Adding the custom merge driver for build.gradle files
  • Change the workflow code so that branches are merged iteratively, giving up on a branch if it can't be merged. Some extra work would be needed to make sure the PR body reflects the PRs that actually made it in.
• If dependabot modifies any GitHub Actions workflows, these need to be excluded with nocombine: the permissions model does not let a workflow modify another workflow, and this is probably for good reason.
• This PR was generated: https://github.com/testcontainers/testcontainers-java/pull/4177
• It seems that GHA workflows are not run against the PR - this is obvious in retrospect (GitHub don't want an infinite loop of workflow runs), but incredibly inconvenient...

[rnorth]

Having thought about it some more, I think this is better as a client-side utility script than a workflow: It seems that GHA workflows are not run against the PR is pretty much a fatal blow, as it prevents us from being able to verify the combined PR actually passes checks.

I've just raised https://github.com/testcontainers/testcontainers-java/pull/4178 using an improved version of my script, which I think addresses the pain points identified above.