Add support for hash partitioning

What does this MR do?

This adds a basic migration helper to create hash partitions. Plus, we create a gitlab_partitions_static schema to hold the partitions.

The reasoning for the extra schema is:

1. We expect to create many partitions - moving them into a separate schema doesn't clutter public
2. Avoid problems with FDW schema checking - individual partitions are not being exported through FDW (and they should not), but the schema checking relies on both the source (schema) and target (schema) to have the same count of tables. By moving partitions into a separate schema, we avoid the mismatch.

For hash partitioning, partitions are static and checked into the codebase. We know a priori which partitions we need and we never create them dynamically. That is, we manage those through usual migrations and we check them into the codebase in db/structure.sql.

This is in contrast to "dynamic partitions" (see !35137 (merged) and the explanation in !34504 (comment 362737531)).

This is a preparation for using hash partitioning in Product Analytics: !35168 (diffs)

This builds upon !35137 (merged). The MR should be changed to target master once the dependency is merged.

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content