feat(experimental): add internal migrate package and SessionLocker interface

[mfridman]

This PR stubs out an internal package migrate that:

• defines a Migration struct which represents either a Go or SQL migration
• adds Run, RunNoTx, and RunConn methods to run the up or down migration
• lazily parses SQL migrations if they haven't been parsed

This PR also introduces a package lock that defines a SessionLocker interface, with a single postgres implementation that uses pg_try_advisory_lock. The default behaviour remains the same, but this should unlock functionality to address #335

---

The intended usage goes something like:

// Create a new provider with a Postgres session locker

locker, err := lock.NewPostgresSessionLocker(
	lock.WithLockTimeout(10 * time.Minute),
)
if err != nil {
	return fmt.Errorf("failed to create locker: %w", err)
}
provider, err := goose.NewProvider(
	goose.DialectPostgres,
	db,
	os.DirFS("path/to/migrations"),
	goose.WithSessionLocker(locker),
)
if err != nil {
	return fmt.Errorf("failed to create goose provider: %w", err)
}

// Application code

resultes, err := provider.Up(ctx)
...

The one downside is the locker implementation is unaware of the dialect, so someone could accidentally call NewPostgresSessionLocker for a non-postgres database.

[mfridman]

I took the best bits of #575 and ported them into this PR.

Kudos to @roblaszczak for suggesting a common interface so users can bring their own implementation. I think this should suffice? Feedback/suggestions are welcome.

I called this "SessionLocker" with the hopes of one day also adding a "TransactionLocker".

The one gotcha here is supplying a locker that doesn't match up with the correct dialect. I tried to name the functions appropriately, but there's nothing enforcing this right now.

[mfridman]

Could argue this is best effort and goose shouldn't fail if a session cannot be unlocked. Need to think about this scenario a bit more.

[mfridman]

This PR doesn't implement the locking / unlocking logic in goose itself, but when we get to that portion, let's make sure to address the feedback in #507 (comment)

[mfridman]

It's possible someone may want to opt out of retries and prefer a blocking operation like pg_advisory_lock

If another session already holds a lock on the same resource identifier, this function (pg_advisory_lock) will wait until the resource becomes available.

I suppose with an option like lock.WithBlocking we could extend and add this logic. While keeping the default as pg_try_advisory_lock with retries.

The alternative is to have a completely different implementation or users just bring their own locker.