This PR fixes a bug where ALTER COLUMN commands with IF EXISTS clause would fail when column state changes between the validation and application phases within the same ALTER statement.

Problem

When multiple ALTER commands are executed in a single statement, some commands can change the metadata state (e.g., DROP COLUMN removes a column), causing subsequent commands in the same statement to fail even when using IF EXISTS clause.
This happens because:

1. During the validate() phase, the column exists, so ignore flag remains false
2. During the apply() phase, the column has been removed by a previous command
3. Commands directly calling metadata.columns.modify/remove/rename methods throw exceptions

For example:

ALTER TABLE t DROP COLUMN c0, DROP COLUMN IF EXISTS c0;  -- Second command fails

Solution

• Added a helper function should_skip_column_operation() for consistent IF EXISTS runtime checking
• Applied runtime checks to all four command types in their apply() methods
• Added comprehensive tests covering all edge cases and command combinations

Changelog category (leave one):

• Bug Fix (user-visible misbehavior in an official stable release)

Changelog entry (a user-readable short description of the changes that goes into CHANGELOG.md):

Fix ALTER COLUMN IF EXISTS commands failing when column state changes within the same ALTER statement. Commands like DROP COLUMN IF EXISTS, MODIFY COLUMN IF EXISTS, COMMENT COLUMN IF EXISTS, and RENAME COLUMN IF EXISTS now properly handle cases where a column is deleted by a previous command in the same statement.