correct email for cases when add-on will not be public despite approval

[eviljeff]

Fixes: mozilla/addons#16058

Description

Adds support to emails for cases where the add-on is not public, despite Add-on|Version|Listing appeal/override.

Context

We previously always assumed that an appeal/override led to the add-on being public, but there are cases where that isn't true.

I ended up refactoring the tests to make it (a little) better to add coverage for these cases.

Testing

The new cases the emails now cover are:

• Content is approved (after a previous content rejection), but the add-on isn't public because no listed versions are approved at the time (rejected, awaiting review, etc)
• an appeal on a listing rejection but the add-on isn't public because no listed versions are approved at the time (rejected, awaiting review, etc)
• an appeal on a force disable, but the add-on isn't public because no listed versions are approved at the time (rejected, awaiting review, etc)
• an appeal on a version rejection, but the add-on isn't public because no listed versions are approved at the time, AND the version that was rejected was awaiting review rather than approved.

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]

Probably want to use is_public() instead of that last one, which handles the edge case of an add-on being set to invisible.