Restore the behaviour of the compatibility layer for integer-like PKs

[kamipo]

Follow up to #26266.

Currently master branch was lost 1fa6c9e (#22090) and #18220 due
to #26266 and #26266 has another regression #27374.

primary key definition	before #26266	after #26266
id: :primary_key (default)	int auto_increment PRIMARY KEY	bigint auto_increment PRIMARY KEY
id: :integer	int PRIMARY KEY	int PRIMARY KEY
id: :integer, default: nil	int PRIMARY KEY	int PRIMARY KEY
id: :bigint	bigint auto_increment PRIMARY KEY	bigint PRIMARY KEY
id: :bigint, default: nil	bigint PRIMARY KEY	bigint PRIMARY KEY

1fa6c9e (#22090) and #18220 are to ease to create an auto incremental
(or not) bigint primary key and to dump the primary key correctly.

Since #26266, changed default primary key, and 1fa6c9e (#22090)
and #18220 were lost. And so currently an auto incremental int primary
key cannot dump (lose auto increment).

To fix the issue, integer and bigint primary key has auto increment
as implicit default, and legacy migration still keep its previous
behavior as before #26266.

primary key definition	suggested fix
id: :primary_key (default)	bigint auto_increment PRIMARY KEY
id: :integer	int auto_increment PRIMARY KEY
id: :integer, default: nil	int PRIMARY KEY
id: :bigint	bigint auto_increment PRIMARY KEY
id: :bigint, default: nil	bigint PRIMARY KEY

---

The PR #27384 changed migration compatibility behaviour.

class CreateMasterData < ActiveRecord::Migration[5.0]
  def change
    create_table :master_data, id: :integer do |t|
      t.string :name
    end
  end
end

Previously this migration created non-autoincremental primary key
expected. But after the PR, the primary key changed to autoincremental,
it is unexpected.

This change restores the behaviour of the compatibility layer.

[rails-bot]

r? @chancancode

(@rails-bot has picked a reviewer for you, use r? to override)

[maclover7]

cc @matthewd

[kamipo]

Legacy migration still have the regression #27334.
Could you also review #27334?