start tracking when crates are yanked

[QuietMisdreavus]

There's currently a column in our database to see whether a release has been yanked, but we don't set it when tracking updates. This PR changes that by adding:

• A change to the build queue that handles yank events by setting the release as yanked,
• A change to the "crate details" screen that adds a banner when the release is marked as yanked in our database, and
• A change to the version resolution code to look up the list of releases of the crate that are marked as yanked in our database, and avoid resolving to yanked releases unless explicitly asked for.
  • (Side note: if all of a crate's versions have been yanked, this will make it appear to not exist if you go to docs.rs/crate. Is this behavior we want? I can make it check whether all versions have been yanked before filtering them out, if desired.)

I also added a test to ensure that the templates are properly formatted, since i messed that up initially. >_>

Fixes #112, Fixes #221

[QuietMisdreavus]

It's worth noting that this will only track yanks that occur after this is merged. I'll look into ways to backfill all the yank events into our database - i bet we can do it from our local clone of the crates.io index, but if that turns out to be infeasible i can ask the Crates.io team for guidance.

[QuietMisdreavus]

After a quick chat on Discord, apparently it's easy enough for the crates.io maintainers to generate a CSV of currently-yanked crates, so whenever this is deployed we can ask for that to backfill yank information.

[jyn514]

From my reading, this does 3 different things:

1. Update the yanked field in the DB when we get a yanked change from crates_index_diff.
2. Feed that yanked field throughout the rest of the code and show a warning on the doc page if it's set.
3. Make the handlebars templates testable.

I would love to have all of these changes, but the PR needs to be rebased. I think @Nemo157 has expressed interest in working on this.