By default, when following a link from a web page delivered via HTTP,
a browser will send the URL of the linking page (the referrer) to the
new server. On the other hand, when coming from an HTTPS page, the
referrer is by default only sent if the target page is delivered via
HTTPS, too. This behaviour is a relic from a time when HTTPS was only
used for, e.g., webmail or banking, and was intended to reduce the
risk of session-key URLs leaking via the referrer. It may also be
useful in some other cases, for privacy reasons; e.g., for a social
media page that is only visible to a specific group of people and
contains a link to an external site, it may be unwelcome that the
external site could find out who referred to it.

For a site like MusicBrainz, however, that is almost completely(*)
public, does not use session keys in its URLs, and is accessible both
by HTTP and HTTPS (and in the future possibly HTTPS only), this
default browser behaviour is not appropriate. It is actually desirable
that target sites (musicians, labels, external databases, etc.) learn
that visitors found them via MusicBrainz.

In order to let sites customize browsers' referrer behaviour, the
referrer policy standard (https://www.w3.org/TR/referrer-policy/) was
developed. The most suitable policy for all-public sites is, despite
its intentionally discouraging name, "unsafe-url", which is the old
default behaviour from before HTTPS: Always send a referrer, whatever
the HTTP/HTTPS status of the origin or target sites is.

This commit accordingly sets a referrer policy header for all web
pages (but not the web service, which isn't normally consumed by web
browsers directly) with a policy of "unsafe-url".

(*) Private collection pages are an exception, but they don't contain
external links - they only link to the entity pages on MusicBrainz
itself.