Use GET HTTP method instead of POST for Browse search

[StephenChan]

Been on my mind for a while now, but I don't think there's an issue for this yet. Advantages:

• Page refreshes and Back/Forward button usage are clunky with POST.
• When Back/Forward button usage is less clunky, it would be easier to retain the search params during annotation tool prev/next navigation, and image details prev/next navigation (not implemented yet; issue #438).
• GET means search params will be in the URL, which means it'd be possible to jump to any page number by modifying the page param in the URL.
• It's more correct for this to be GET rather than POST, since no data is being modified. We'll particularly want to use the correct HTTP method if Browse search gets adapted to the API at some point.

Implementation concerns:

• When you finish an image upload, there's a button which lets you manage metadata for the images you just uploaded. It does this by specifying the image IDs in the request. This may force us to have potentially 1000s of image IDs (each 7 digits) in the URL, which feels... clunky. So for this, I'm thinking of using a specification like 'get images past this upload date / past this ID', rather than 'get images of these IDs'.
• The annotation tool is POST for a couple of reasons right now. First, the current implementation of prev/next navigation requires it, and second, the annotation tool view actually does modify data: it creates an AnnotationToolAccess record, and it may apply Alleviate. I think we should also change the annotation tool to GET to make Back/Forward less clunky, but it'll take a couple of extra steps: AnnotationToolAccess and Alleviate need to be separated into Ajax requests which run upon loading the annotation tool.