Description

Historically, we tracked escalations, where jobs are moved from one queue to another, via a foreign key, forwarded_to_job on CinderJob.
Then, when Cinder implemented queue moving as escalation, we switch to that, and created a QueueMove model to track it.
With mozilla/addons-server#23301 we started tracking 2nd level approval requeue events as pseudo-decisions (with ContentDecision instances) - at this point we had 3 ways for jobs to "move"
After forwarded_to_job was dropped in mozilla/addons-server#23338 we were down to 2 ways - if we can refactor how queue moves are tracked, so they are also stored as ContentDecision instances, then we will have a single, consistent, way of tracking job "moves" (they should still be differentiable when we need to expose the information)

Acceptance Criteria

• QueueMove model dropped
• queue moves stored as ContentDecision, with a specific action
• existing moves are backfilled/migrated to ContentDecisions, so no data is lost.

┆Issue is synchronized with this Jira Task