In the Details page, if the user click "Ping Now",
and the project is using {ping-key}/{slug} URLs,
but the ping key is not set, then show a
"Ping Key Required" message instead of trying to ping
and invalid URL.

cc: #547

In a project with ~300 checks,

* HTML size (uncompressed) before: 772KiB
* HTML size (uncompressed) after: 703KiB

In SMS, Signal and WhatsApp forms, reject the form if
user unchecks both "alert when check goes DOWN" and
"alert when check goes UP".

cc: #552

cc: #552

cc: #547

This commit adds a {% absolute_site_logo_url %} template tag.
The tag emits an absolute url pointing to either
SITE_LOGO_URL or to the fallback picture.

The tag is used in base email template, in slack message
template, and in "Add MS Teams" page.

This commit also fixes a couple instances where absolute URLs
were constructed like so:

    {% site_root %}/docs/

This would result in incorrect links if Healthchecks is not
running at webserver's root. The correct way is:

    {% site_root %}{% url 'hc-docs' %}

Finally, this commit removes stuff/logo.svg and
stuff/logo-full.svg. Selfhosted sites should not use the
official Healthchecks.io logos, so no point keeping them around
there.

Fixes: #550

cc: #547

cc: #547

cc: #547

If user has both WebAuthn and TOTP configured,
when logging in, they will be asked to choose between
"Use security keys" and "Use authenticator app".
The "Use authenticator app" is a link to a different
page (/accounts/login/two_factor/totp/). This commit makes
sure the ?next= query parameter is preserved when navigating
to that page.

For reference, the ?next= query parameter is the URL we should
redirect to after a successful login. Use case:
User is logged out. They click on a bookmarked "Check Details"
link. They get redirected to the login form. After
entering username & password and completing 2FA,
they get redirected to the "Check Details" page they
originally wanted to visit.

This has dual purpose:

* if user has both WebAuthn and TOTP set up, they can choose
  between the two as equal options.
* we initiate WebAuthn flow only after an explicit user action
  (button press). This may help with authentication failures
  on recent MacOS, iOS and iPadOS versions [1]

[1] https://support.yubico.com/hc/en-us/articles/360022004600-No-reaction-when-using-WebAuthn-on-macOS-iOS-and-iPadOS

Fixes: #354