Building the user manual was hitting a problem when trying to serialize links for the DraftFileAttachmentResource, where it wasn't finding the right review request. After a trip far down the rabbit hole, I narrowed this down to a bug in djblets.webapi.resources.base.WebAPIResource.get_object, and the caching that it does. This method attempts to keep a cache of objects, which is stored on the request object. Unfortunately, the cache key computation is broken for resources which are singleton but are children of non-singleton resources. In this case, ReviewRequestDraftResource is marked as singleton, but its parent resource is not singleton. We really ought to be chaining up the tree of resources and letting each one contribute to the cache key. Because changing the cache behavior in djblets is very risky right now (even with a known bug of this magnitude), we're going to work around this entirely in the docs code. This code exposed the bug because it uses the same request object for everything. In order to work around it, we create new requests for each `get_queryset()` call as we iterate through the resource tree. While I was here I fixed up some problems I found in the fixtures with the file attachment and screenshot counts, where the counts had somehow ended up with the values typed twice (33 instead of 3, for example). Testing Done: Built user manual.