Add TYPE_VARBINARY for proper binary type distinction

[dereuromark]

Summary

This is a BC-breaking alternative to #19207 that adds a proper TYPE_VARBINARY constant instead of using a fixed attribute on the binary type.

• binary type now always generates BINARY (fixed-length)
• New varbinary type generates VARBINARY (variable-length)
• SQLite/PostgreSQL map both to BLOB/BYTEA respectively (no distinction in those databases)

CakePHP Type	MySQL	SQLite	SQL Server	PostgreSQL
binary	BINARY	BLOB	BINARY	BYTEA
varbinary	VARBINARY	BLOB	VARBINARY	BYTEA

This mirrors the existing pattern for string types where char → CHAR and string → VARCHAR.

[dereuromark]

Migration Impact

For users upgrading to 6.x, existing migrations using the binary type with fixed => true will need to be updated:

Before (5.x with #19207):

// Fixed-length BINARY(20)
$table->addColumn('hash', 'binary', ['length' => 20, 'fixed' => true]);

// Variable-length VARBINARY(20)
$table->addColumn('data', 'binary', ['length' => 20]);

After (6.x with this PR):

// Fixed-length BINARY(20)
$table->addColumn('hash', 'binary', ['length' => 20]);

// Variable-length VARBINARY(20)
$table->addColumn('data', 'varbinary', ['length' => 20]);

The fixed attribute is no longer used for binary types. Instead, use the appropriate type directly:

• binary → fixed-length BINARY
• varbinary → variable-length VARBINARY

Schema reflection will now correctly identify VARBINARY columns as type varbinary instead of binary, ensuring proper round-tripping in migrations.

[markstory]

The fixed attribute is no longer used for binary types. Instead, use the appropriate type directly:

It doesn't feel great to be introducing a new option in 5.3, and then breaking that behavior in the next major. Perhaps it won't matter much as varbinary is hopefully an infrequently used datatype?

[markstory]

Keeping this for compatibility seems like a reasonable compromise. At least then we aren't breaking something we recently shipped. It would give two ways do express varbinary/binary columns but we could avoid the breaking change.