Add support for deleting KitRequests from items. There's functionality to prevent editing a KitRequest if it's used by more than one item, but that should never actually be true, because we don't provide the functionality to add an existing kit request to an item - only kit requests we're creating on the fly. Still need to avoid the creation of standalone kit-requests.
Use a different template, kitrequest_list.html, for listing kit requests. This includes the list_kitrequest.html sub-template, and doesn't include an "add new" option. Also remove the "add new" option from the drop-down menu for KitRequests. This now means that the KitRequest menu and page is purely a listing, and identical to what we get on the Kit Usage page, so there's not a great deal of point in keeping it.
Remove some dead code.
Use a dedicated template for list_kitbundles, and add some methods to KitBundle to determine which rooms and items it's assigned to, so that we can display that in the template. Still need to implement deleting KitBundles.
Support deleting KitBundles.
Add a custom template for listing KitThings, including the deletion functionality, and checking for Things that are in use, somehow.
Don't allow deletion POSTing, unless there are permissions to do so. (Should also add this on the View itself…)
KitBundle list didn't include links to the actual bundles.
Updating current state of kit pages.
Add a new generic function to views.py, to initialise a form's content to an item, a room, a KitThing or a KitBundle, depending on whether the query-string contains item, room, thing or bundle. This is then used by a number of Add links to configure the page accordingly. This isn't quite the same as the add-person-to-item approach, because that's a class-based-view approach, but allows us to select whether we bounce off to one or the other object upon submit. Haven't added that capability yet.
Fixing a couple of bugs that meant we assert on checking for unsatisfied kit requests. Added some tracing.
There's a bug with the logic, though, in that we say (item does all own requests) OR (item's room does all item's requests), so we fail if there's a mixture of (item) and (item's room).