Please improve migrate command to work same as rollback when target is set to an old migration ID

Currently migrate command does not respect version_order:execution config or breakpoints like rollback command does.

I have a CD environment for our main codebase. I'm using phinx in a separate codebase to manage its database. I'm using the version_order:execution config. For each CI build that triggered by a code merge, I store the Migration ID in the artifact. Then during deployment, I want to run migrate -t {Migration ID} together with the main artifact deployment. Please note this need to support rolling back the entire system to an old artifact.

Right now, when if I run migrate -t {Migration ID}, where {Migration ID} is in the past when I do a system roll back, phinx will rollback all the migrations that are created after that {Migration ID} and disregard any existing breakpoint. I think this is wrong, it should detect the {Migration ID} is in the past then perform same behaviour as rollback -t {Migration ID}, which respect the version_order:execution config and any breakpoint.

For the CD environment I described above, this is very important because I can then have a consistent method to handle database migrations for my deployments, doesn't matter if it is a new release or a rollback.

My workaround right now is that in the deployment process, I have to check if the {Migration ID} is up or down. If it is down, I call phinx migrate -t {Migration ID}; if it is up, I will have to call phinx rollback -t {Migration ID}.

Thanks.

Start with the migrate and rollback command paths described in the issue, focusing on target handling when the requested migration ID is in the past. Reproduce the case with version_order:execution and an existing breakpoint, then verify that migrate -t matches rollback -t behavior for rollback deployments without changing forward migrations.