Set `creator_id` to nil on projects whose creator is now non existent

What does this MR do and why?

Premise

Until 3 months ago, that is, until we merged !102163 (merged), a User could be deleted, but their ID would remain in the Project#creator_id column and wasn't being nullified on User destroy.

Now that we have that dependent: :nullify relationship here, the next step is to nullify the Project#creator_id column for projects whose creators (ie, users) have already been deleted from the database. This ensures that the data in this column is clean.

This MR attempts to do that via a batched background migration.

Total count

Total count of Project records that needs update on gitlab.com database as on 1-Feb-2023: 60262 (Source)

Migrations

UP Migration

$ bundle exec rails db:migrate
main: == 20230130073109 NullifyCreatorIdOfOrphanedProjects: migrating ===============
main: == 20230130073109 NullifyCreatorIdOfOrphanedProjects: migrated (0.0540s) ======

ci: == 20230130073109 NullifyCreatorIdOfOrphanedProjects: migrating ===============
ci: -- The migration is skipped since it modifies the schemas: [:gitlab_main].
ci: -- This database can only apply migrations in one of the following schemas: [:gitlab_ci, :gitlab_shared, :gitlab_internal].
ci: == 20230130073109 NullifyCreatorIdOfOrphanedProjects: migrated (0.0041s) ======

DOWN Migration

$ bundle exec rails db:rollback:main STEP=1
main: == 20230130073109 NullifyCreatorIdOfOrphanedProjects: reverting ===============
main: == 20230130073109 NullifyCreatorIdOfOrphanedProjects: reverted (0.0230s) ======

$ bundle exec rails db:rollback:ci STEP=1
ci: == 20230130073109 NullifyCreatorIdOfOrphanedProjects: reverting ===============
ci: -- The migration is skipped since it modifies the schemas: [:gitlab_main].
ci: -- This database can only apply migrations in one of the following schemas: [:gitlab_ci, :gitlab_shared, :gitlab_internal].
ci: == 20230130073109 NullifyCreatorIdOfOrphanedProjects: reverted (0.0063s) ======

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.

Related to #378477 (closed)