Bug: DROP COLUMN ordered before dependent view's DROP within same group, apply fails

[serzh]

Destructive sibling of #414. When a column is dropped and a view that references it is recreated in the same plan, pgschema emits the ALTER TABLE DROP COLUMN before the DROP VIEW. Both end up in the same implicit transaction; Postgres refuses the column drop because the live view still depends on it.

pgschema 1.9.0.

Starting state:

CREATE TABLE foo (id bigint PRIMARY KEY, keep_me text, drop_me text);
CREATE VIEW foo_v AS SELECT id, keep_me, drop_me FROM foo;

Desired state (foo.sql):

CREATE TABLE foo (id bigint PRIMARY KEY, keep_me text);
CREATE VIEW foo_v AS SELECT id, keep_me FROM foo;

Run:

pgschema plan  --schema public --file foo.sql --output-json plan.json
pgschema apply --schema public --plan plan.json --auto-approve

Actual plan (transaction group 1):

ALTER TABLE foo DROP COLUMN drop_me;
DROP VIEW IF EXISTS foo_v RESTRICT;
CREATE OR REPLACE VIEW foo_v AS SELECT foo.id, foo.keep_me FROM foo;

Apply:

Executing group 1/1...
  Executing 3 statements in implicit transaction
Error: failed to execute concatenated statements in group 1:
ERROR: cannot drop column drop_me of table foo because other objects depend on it (SQLSTATE 2BP01)

Expected order:

DROP VIEW IF EXISTS foo_v RESTRICT;
ALTER TABLE foo DROP COLUMN drop_me;
CREATE OR REPLACE VIEW foo_v AS SELECT foo.id, foo.keep_me FROM foo;