Introduce versioned GitLab migration class

What does this MR do?

Introduce a "versioned" parent class for database migrations

This introduces a versioned parent class for database migrations.

This implements a simple versioning scheme for migration helpers.

We need to be able to version helpers, so we can change their behavior without
altering the behavior of already existing migrations in incompatible ways.

We can continue to change the behavior of helpers without bumping the version here,
*if* the change is backwards-compatible.

If not, we would typically override the helper method in a new MigrationHelpers::V[0-9]+
class and create a new entry with a bumped version below.

We use major version bumps to indicate significant changes and minor version bumps
to indicate backwards-compatible or otherwise minor changes (e.g. a Rails version bump).
However, this hasn't been strictly formalized yet.

Background and follow-ups

In #339115 (closed), we need to change the behavior of with_lock_retries in an incompatible way (raise an exception if used inside an already open transaction). In order to keep the behavior for existing migrations the same, we need some sort of versioning. This is what we introduce here.

The main MR I'm working on is !68942 (merged), which has a few more changes, specifically to with_lock_retries.

This MR here is an extract. Except for syntactic sugar, this doesn't have an effect, except: New migrations will be using the V2 module for migration helpers automatically from now on.

How to setup and validate locally (strongly suggested)

1. Generate an example migration with rails g migration TestMigration
2. Fill in some steps, e.g. execute 'select pg_sleep(1)' for up
3. Run the migration with rake db:migrate

Also check the cop is able to complain about a migration that looks like any of the existing migrations (inherit from ActiveRecord::Migration[] or include the migration helpers explicitly.

Does this MR meet the acceptance criteria?

Conformity

• I have included changelog trailers, or none are needed. (Does this MR need a changelog?)
• I have added/updated documentation, or it's not needed. (Is documentation required?)
• I have self-reviewed this MR per code review guidelines.
• I have followed the style guides.
• This change is backwards compatible across updates, or this does not apply.