Mechanism for fetching previous page

Related to #20 but distinct.

Right now, a results page includes a next_page cursor. If you want to get the previous page, you're out of luck unless you just came from that previous page and held onto the cursor. That's what we are currently doing in the console: we keep a stack of page cursors as you page through, and pop() to go back. But if you lose that stack (for example if the console page is refreshed) then you have no way of going back. (It's worth noting that in the console, we're not yet keeping track of the current page cursor in the query string, which means when you refresh you'll actually get sent back to page 1. But that's a temporary state of affairs. We will have it in the query string eventually. The lack of previous page functionality is a big reason it has not been worth doing yet.)

Off the top of my head I can think of two approaches: one bad, one good.

Add prev_page cursor to the paginated response

The Dropshot consumer would have to fetch an extra N items in order to get the cursor for the first item in the previous page. That seems ridiculous.

Add param that lets you ask for the page before a given cursor

This is what Stripe does.

https://stripe.com/docs/api/pagination#pagination-starting_after

Our page_token param is roughly analogous to their starting_after param, but theirs is a little different because rather than giving it a cursor for the first item in the page you want, you give it the ID of the last item in the previous page. This works because they use item ID as the cursor instead of an opaque token. This also means they don't have another problem we have: if we ask for the previous page from a given cursor, we'd need the response to include the cursor for the first item in the result page, otherwise we'd have now way of fetching the page before that. With Stripe, you can just pull the ID off the first item in the previous page and ask for the page before that.

Start by reviewing Dropshot's paginated response and page_token handling, then compare the two cursor approaches described in the issue. Trace how a caller would fetch earlier pages after losing its cursor stack. Done means the backward-pagination API behavior and implementation scope are clearly decided.