[BUG] `update-dask-sql.yml` workflow will pull future branches

[raydouglass]

If a new version of dask-sql is released, update-dask-sql.yml opens a PR to update to the new version. If this PR is not merged before code freeze, after code freeze when the default branch is switched, the update-dask-sql.yml will open a second PR targeting the new branch.

The problem with this is that the PR targeting the "old" and "new" branches use the same branch. So the "old" PR will have changes from to the "new" branch that should not be back ported.

Examples: #572 & #575

[bdice]

cc: @galipremsagar @charlesbluca When we finalize dask pinnings and/or do a dask-sql release for a given RAPIDS release, maybe we can add a step in the process to make sure it’s picked up here before code freeze?

[charlesbluca]

Yeah that makes sense to me - in general, there's not been too much friction integrating dask-sql with the rest of RAPIDS, but when things break they can break quite spectacularly so I'm happy to take more of a hands on process with bumping things 🙂

For the issue itself, it's worth noting that we should be able to explicitly set the branch getting checked out for the PR and the base branch for the PR (though it defaults to the checked out branch); would it help here to explicitly set that branch in the workflow file (or even parametrize to check out and open/update multiple PRs) and have it get updated with the version updater script?