Ensure that inferred migrations are named appropriately with respect to user created migrations to ensure correct lexicographical ordering of migration files on disk.

Reproduction

Before this PR, the problem with inferred migration naming was reproducible as follows:

Create the following migration as 01_first_migration.yaml:

operations:
  - sql:
      up: SELECT 1

Apply the migration with pgroll start --complete .

On the target database, run some DDL:

CREATE TABLE foo(a int PRIMARY KEY);

Create another migration, 02_second_migration.yaml:

operations:
  - sql:
      up: SELECT 1

Apply the migration with pgroll start --complete .

Now pull the migration history into a temporary directory:

$ pgroll pull tmp/

The migration history is not in the correct lexicographical order; the inferred migration is ordered after the user-created migrations:

├──  01_first_migration.yaml
├──  02_second_migration.yaml
└──  sql_1fb6e25eba9678.yaml

New behaviour

This PR fixes the problem by naming inferred migrations so that they appear in the correct lexicographical order when pulled to disk with pgroll pull:

The same steps as in the reproduction now result in these files on disk:

├──  01_first_migration.yaml
├──  01_first_migration_20250613120930931268.yaml
└──  02_second_migration.yaml

The inferred migration is now lex-ordered correctly between the two user migrations by appending a fixed width timestamp suffix to the previous migration name.

The inferred migration has its version_schema field set:

cat 01_first_migration_20250613120930931268.yaml:

version_schema: sql_e842123c
operations:
- sql:
    up: create table foo(id serial primary key)

This is to ensure that the version schema for the inferred migration does not risk exceeding the Postgres 63 character limit for schema names.

Fixes #882