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 
I considered doing that but each table has a different number of columns, from like 2 to 8. Rather than manually setting %s for each one I figured I'd just do one render and then figure out the %s based on how chrome sizes the table and set that as the final value.

It's not really necessary to do it this way, I just felt this is an easier solution. What do you think? I do agree that the code is a little messy though, I'll look into changing it.