Expose more relevant information for developer appeals

[eviljeff]

Fixes mozilla/addons#16266

Description

Refactors the widget for CinderJobs to be more maintainable, and separates rendering of developer appeal jobs to show information about the appealed decision(s).

Context

• This patch focuses on developer appeals because a reporter appeal is only possible on an approval decision, information about that decision isn't really relevant - it's the original reports that are important. Whereas for developer appeals, we care more about how the add-on/versions were affected. So this PR only (functionally) changes developer appeals.

Testing

• set up your cinder integration
• enable waffle switch enable-policy-review-selection (and the Cinder relatedd waffle switches)
• report an add-on for abuse via frontend for policy violation
• edit the CinderJob that was created in django shell to set resolvable_in_reviewer_tools=True
• navigate to the review page for that add-on
• open the Negative Review reviewer tools action, and see the job shown below, with details of the abuse report you made (all existing functionality - checking no regressions)
• made a decision on that add-on, resolving the job, for some policy that does something negative to the addon/version
• check in fakeemail for the email to the developer, and appeal that decision with the link in email.
  • (You will need to add yourself as an author of the add-on first. Easiest way is via django shell AddonUser.objects.create(addon_id=<id>, user_id=<your userid>))
• go back to the review page.
• open Resolve Appeals with Denial or Resolve Appeals with Override and see the appeal job for the appeal you submitted. It should show the decision that was made, along with your appeal justification, and any versions that were affected

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.