Split up job data dimension

[jjnesbitt]

This PR accomplishes the following:

1. Split up JobDataDimension into the following dimensions:

   • SpackJobDataDimension
   • GitlabJobDataDimension
   • JobResultDimension
   • JobRetryDimension

   This data was all bundled into the JobDataDimension, which necessitated an entry in that dimensional table for every job. This meant that the JobDataDimension table was as large as the JobFact table, which is undesirable, and results in poor join performance. With this dimension split up, each table is much smaller, which results in more re-used rows, as well as faster joins.

2. The storage of gitlab section timers on the JobFact table. Since this is numeric, and will have aggregations performed on it, it's the correct place to store it.

3. Setting the job_id as the primary key for the JobFact table. This is really how we expect these facts to exist anyway (only one job fact per job). As a result of the old primary key for this table, there were actually several duplicate job entries, which this PR cleans up.

4. The removal of the JobDataDimension table. This is due to all of its constituent data being split into smaller dimension tables. However, this also results in the removal of that foreign key from the TimerFact and TimerPhaseFact tables, although they still store the job_id. I plan to evaluate if and what new relations should be introduced, and make those changes in the future.

I have run these migrations locally and can confirm there are no errors that arise. I also have tested some webhook payloads and it seems the job processor runs without error. The migration downtime for this should be ~6 hours in production.