This adds our own custom replication between the CFbot and the
commitfest app. We currently keep the last CFbot runs in our database,
in an attempt to keep the queries easy and efficient. The CFbot results
are now shown on the overview page of each commitfest, as well as on the
page for each specific patch.

In previous commits (2ada851 & b6010e9) some initial links and git
checkout instructions were added to the patch page. I received some in
person feedback at PgConf EU that those used quite some vertical space
on the page.

Now that we have a dedicated row in the table for CFbot statuses, it
seems natural to integrate those previous links and checkout
instructions into that row. Both to keep all CFbot content together, as
well as to reduce vertical space needed.

To reduce the necessary space needed for the checkout instructions,
these previously explicit checkout instructions have been changed to
button that copies the required commands to the clipboard.

Finally, this also makes "Needs rebase!" link to CFbot logs instead of
CI results. I updated these logs recently on the CFbot side to become
much more useful to look at, by making them actually show the conflicts.

This is needed to send notifications to a patch author that it
subscribed. We don't send updates to other subscribers to the patch, as
this information is generally only useful for the author themselves.

By using the "history item" infrastructure it's also displayed on the
patch page in the "History" table. That seems quite useful too, because
it makes it clear how long the patch has needed a rebase.

This is mostly useful to avoid people from adding trailing whitespace to
files.

The ID of a CF entry is the only stable identifier (people can change
the name). That's why tooling such as CFbot uses the ID of the patch for
a lot of things (including showing it on the cfbot overview page).
Having it visible on the page is quite useful for debugging purposes

In eee60a5 the ID was added to the title of the entry, but that made the
the title of the page itself less prominent. So this is an attempt to
have the information available, but not too prominently visible.

If the commitfest entries are sorted by a column clicking the header
again will now remove the sort. In a future commit, it would be nice to
also support for reverse sorting.

It was pretty confusing that clicking the patch name header would sort
by created time, grouped by topic. This makes that sort by name.

Sorting order impacts closed patches too. So not showing the arrow that
indicates sort direction on that header is confusing. While we're at it,
we might as well allow people to toggle sorting direction using that
header too.

This also automatically fixes the problem that the cell in the closed
patches header did not contain any title at all.

Previously we'd include the ID of the commitfest in the URL of the
patch. In 9f12a5e we introduced a stable URL for patches that would
redirect to the one for the latest commitfest. This starts to use that
URL as the valid only URL for a patch (with the previous URL redirecting
to this one).

The reasoning behind this is that the old approach resulted in N
different URLs for each patch, which all showed the exact same patch
information. The only difference between all these URLs would be the
breadcrumb at the top of the page.

The only benefit of that approach is that if you're on an old
commitfest, and click a link there, then the breadcrumb will bring you
back to where you came from. Since people rarely have a reason to browse
closed commitfests, the that benefit seems pretty small. Especially
because people can just as well press their browser back button, in that
case.

The problems that these N links cause seem much more impactful to most
users:

1. If you click an old link to a cf entry (e.g. one in the email
   archives), then the breadcrumb will contain some arbitrarily old
   commitfest. It seems much more useful to have the breadcrumb show the
   commitfest that the patch is currently active in (or got
   committed/rejected in).
2. Places that use the stable URLs require an extra round-trip to
   actually get to the patch page.
3. It's a bit confusing that old pages of a patch still get updated with
   all the new information, i.e. why have all these pages if they
   contain the exact same content.
4. Problem 3 is generally also bad for Search Engine Optimization (SEO),
   for now we don't care much about that though.

Finally this also changes the links on the patch page itself for each of
the commitfests that a patch has been part of. Those links were already
rather useless, since all they effectively did was change the
breadcrumb. But with this new commit, they wouldn't even do that anymore,
and simply redirect to the current page. So now they start pointing to
the commitfest itself, which seems more useful behaviour anyway.