Use bigint for new installations

Proposal

Convert structure.sql to use bigint for primary key columns. This idea came from a discussion on Cells between @ayufan and @NikolayS - https://www.youtube.com/watch?v=xE_l9vaL9-0, and discussed in the last @gitlab-org/database-team sync call.

Pros:

• All new installs will use bigint, and will not have to migrate.
• Cells will have a larger PK range to use in order to implement unique PKs across the cluster.

Cons:

• Future conversion migrations will have to take into account if the column is already bigint. We already have done this, when migrated notes and related tables for GitLab.com first, and committed the changes to structure.sql, so we know how to do it (example).
• Existing installations will have database schema that has diverged from structure.sql.
• We'll need to have a way to exclude such inconsistencies when gitlab:db:schema_checker is executed.

We can have a migration that will execute for dev and test environments only, and bulk migrate all integer PKs to bigint using ALTER TABLE. This will resolve the problem for development environments, and by committing the changes to structure.sql, all new installations will use bigint.

We'll need to provide an easy way for developers to revert back to integer for when they start work on migrating a column for existing installations, e.g. like rake task and will documented process.