Implement decision overrides in reviewer tools

[eviljeff]

Fixes mozilla/addons#16242

Description

When making a new decision, optionally allows selecting an existing decision to be overridden. When this happens the enforcement action for the existing decision is reversed first.

For complex cases where the decision to be overridden needs to be reversed first, there is an "Override Reverse-only" policy for the first override.

Selecting a previous decision to override also force-shows (unhides) the versions that were affected by that decision, meaning you can choose versions to be affected by the new decision even if their status would usually hide them.

Context

Turned out to be quite a large pr! Properly overriding involved a lot of changes - really the PR is much more about ActionClass changes and not much in the reviewer tools code. The reviewer tools changes are mainly about exposing the versions affected by the overridden decision.

I had claude write the refactoring changes with overrides in abuse/actions.py, abuse/models.py, and the associated tests. I read all the changes, and they seem reasonable, but worth paying special attention nevertheless. I then followed up that refactoring with some manual clean-up and fixes.

Testing

Sync your Cinder policies + turn on waffle switch + enable the new Override Reverse-only for reviewer tools in django admin

Try:

• overriding a decision directly with a new decision (e.g. disable with approve) - should reverse and send an email
  • if the new policy involves an action with versions selection (e.g. reject or approve version) you will see the target versions from the old decision are dynamically made available in the version list for selection
• overriding to Override Reverse-only policy - shouldn't send an email
• then overriding that override to a new decision (should sent an email)

Checklist

• Add #ISSUENUM at the top of your PR to an existing open issue in the mozilla/addons repository.
• Successfully verified the change locally.
• The change is covered by automated tests, or otherwise indicated why doing so is unnecessary/impossible.
• Add before and after screenshots (Only for changes that impact the UI).
• Add or update relevant docs reflecting the changes made.

[diox]

Example: previous decision disabled the add-on, and so all the versions; reviewer wants to override the disable with an an approve version, but those versions are not available for selection for the approve version.

I don't think that should be possible/allowed. If the add-on itself was disabled, we shouldn't allow an approve version, the force-disable should be reverted first separately.