Staged rendering for Requests table

Instead of rendering a monolithic table, it now:

* Deserialises data from API
* Filters & sorts the data in-memory
* Renders one chunk of the table
* If the user scrolls to the bottom, it renders another chunk
* If the user requests a filter or tries to sort the table, go to the second point again.

Also the table column width is fixed based on the widths of the first stage of rendering to improve performance.

The table should now be able to handle any amount of requests. The only thing that'd slow it down now is having too much data to deserialise. Currently on my Air it takes ~.3-.4s to process the 780ish Requests we have.

@tpetr @wsorenson 
If I follow, this logic is used to let the table dynamically size columns on the first render, but then give hardcoded widths so that it doesn't change column sizes later. I'd think that you could get most of this out of setting percent widths on some of the columns in the original CSS (plus starting with `table-layout: fixed`). 

I know that isn't quite as dynamic or flexible, but I don't think that is really necessary since the column sizes are mostly consistent. Just seems to me that this extra complexity isn't really worth it.