Profile.next_nag_date tracks when the next hourly/daily reminder
should be sent. Normally, sendalerts sets this field when
a check goes down, and sendreports clears it out whenever
it is about to send a reminder but realizes all checks are up.

The problem: sendalerts can set next_nag_date to a non-null
value, but it does not clear it out when all checks are up.
This can result in a hourly/daily reminder being sent out
at the wrong time. Specific example, assuming hourly reminders:

13:00: Check A goes down. next_nag_date gets set to 14:00.
13:05: Check A goes up. next_nag_date remains set to 14:00.
13:55: Check B goes down. next_nag_date remains set to 14:00.
14:00: Healthchecks sends a hourly reminder, just 5 minutes
       after Check B going down. It should have sent the reminder
       at 13:55 + 1 hour = 14:55

The fix: sendalerts can now both set and clear the next_nag_date
field. The main changes are in Project.update_next_nag_dates()
and in Profile.update_next_nag_date(). With the fix:

13:00: Check A goes down. next_nag_date gets set to 14:00.
13:05: Check A goes up. next_nag_date gets set to null.
13:55: Check B goes down. next_nag_date gets set to 14:55.
14:55: Healthchecks sends a hourly reminder.

- Add requirements for debian hosts
- Add section that explains how to add new docs.

See also: #483

Not all email clients are formatting the `ping.body` contents uniformly. Even using different applications from the same email provider results in a different display of the `ping.body` contents. There are two basic issues:
* Not all email clients are honoring the fixed-width font that should be used inside `<pre>` tags. Using fixed-width font is listed in the definition on https://www.w3schools.com/tags/tag_pre.asp
* Not all email clients are displaying the text with a 1em line height. This was a recent change to the healthchecks WebUI in 9fd9c8e4ef but is not part of the definition of the `<pre>` tag. I'd like to add this to the emails to make Healthchecks more uniform between the website and the email notification.

Gmail Webmail:
- [x] Is using fixed-width font
- [ ] Line height is set by the webmail client to 18px
Gmail Android App:
- [ ] Text is not fixed-width
- [ ] Line height has extra padding

ProtonMail Webmail:
- [x] Is using fixed-width font
- [x] Line height is correct
ProtonMail Android:
- [ ] Text is not fixed width
- [ ] Line height has extra padding

The testing I performed is not extensive, but it does show how multiple clients are displaying the contents differently. To make the display of the `ping.body` more uniform I'd like to add a bit of formatting information to the `<pre>` tag.

The line height in the ping request body is being set by the bootstrap.css body tag to 1.42857143. The additional line height makes request bodies with unicode characters have spacing between lines that shouldn't be there.

Fixes: #486

so you can see whether it's up or down at first glance

If the notification does not exist, or is more than a hour
old, return HTTP 200 (instead of 400 or 404) so the other
party doesn't retry over and over again.

Accept all expressions that croniter accepts.
If cron-descriptor throws an exception, don't show the
description to the user.

Fixes: #472

Problem: if you use uBlock Origin, and enable the
"Fanboy's Social" filter list, Healthchecks does not show
Telegram or WhatsApp icons. This is because the filter list
contains "##.icon-telegram" and "##.icon-whatsapp" entries.

This commit changes the CSS class prefix to "ic-". So we're
now using icon classes like "ic-telegram" and "ic-whatsapp".

As a bonus, we save 2 bytes in HTML per displayed icon :-)

The following vulnerabilities are fixed by pinning transitive dependencies:
- https://snyk.io/vuln/SNYK-PYTHON-DJANGO-1066259

Previously, I had changed the default value to "", to force
users to set the SECRET_KEY value (the app refuses to start
if SECRET_KEY is empty).

The problem with that is, out of the box, with the default
configuration, the tests also don't run and complain about the
empty SECRET_KEY.

So, a compromise: revert back to the default value "---".
At runtime, if SECRET_KEY has the default value, show a  warning
at the top of every page.