The OverdueFinalizeBackgroundMigration  keep is a script that is run in
CI for generating merge requests to
[finalize batched background migrations](https://docs.gitlab.com/ee/development/database/batched_background_migrations.html#finalize-a-batched-background-migration).

Per our documentation we can only finalize a batched background
migration added before the last "required stop" which is the minimum
versin someone must upgrade to before they can upgrade to this version
of the code.

We were hardcoding that version in the keep before but now we have
MIN_SCHEMA_GITLAB_VERSION which is exactly for this purpose we don't
need to hardcode it anymore. We also changed from `<` to `<=` now that
this version refers to the version of the last required stop rather than
the first version after it.

Also extract some shared logic to Groups helper

Move RuboCop autocorrect call into a helper method so it's easier to
reuse.

Pass existing logger instance to allow keeps to log.

This `force: true` option seems to generate the migration even if there
is an existing migration with the exact same name. Additionally it
deletes the existing migration with the same name. This is probably not
something we ever intended to do so I'm removing it.

At some point we may want to update this to skip finalizing a BBM if a
migration with a matching name exists (or generate a guaranteed unique
name) but it's not clear to me if we actually have a use case for this
now. Also there are plans to be more strict about not re-using batched
background migrations so possibly the matching name won't be very common
in future.

Previously we were determining the gitlab_schema from the `table_name`.
This is causing problems as we're migrating lots of tables to
`gitlab_main_cell`. But the `gitlab_schema` must exactly match whatever
schema was used to queue the batched background migration (see
https://docs.gitlab.com/ee/development/database/batched_background_migrations.html#finalize-a-batched-background-migration
) . As such we've extracted this value from the migration record in the
database which should always be the expected value.

This `-r keeps/...` is proving to be unnecessary and likely it's fine to
just always load all the files in `keeps/*.rb`.

I considered the possibility of loading everything in `keeps/*.rb` as
well as keeping the option around in case someone wanted to manually
load a keep that was in a different directory but I couldn't think of
any good reason to do that. So to simplify the options I've just removed
it.

This will be used by Keeps to determine which group is responsible
for a given feature category, which allows a suitable (backend)
reviewer to be selected.

This is not picked up by keeps/overdue_finalize_background_migration.rb
because it is grepping for `MIGRATION =`. That is the standard way that
it's generated and documented and this was the only occurence so I
figured I'd just fix this rather than making the keep more flexible.

This adds the `gitlab-housekeeper-authored` label to all MRs and ensures
the commit message and MR always have the housekeeper link included so
that we don't need to add that manually in the keeps anymore.

It also adds some `purple` color to the dry-run output for the titles. This
makes them easier to read.

This was followup feedback extracted in
https://gitlab.com/gitlab-org/gitlab/-/issues/435618 for
`gitlab-housekeeper`.

The original implementation of `gitlab-housekeeper` can be found in
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/139492 and it is a
local developer tool for automatically generating merge requests for
repetitive tasks like finalizing batched background migrations. It is a
gem you can run from the command line and is being actively developed to
eventually run as a periodic job to save us from many manual repetitive
MRs.