WIP: Updating the query to be simpler

@ormsbee @wedaly 

So here's where I stand tonight:
I've made some small changes that should improve performance slightly, such as dropping the 'order by' statement, since it mimics the default ordering, and actually appears to cost us query time.  I dropped the check for the completed_at timestamp, because its not relevant. 

The major change to the queries introduces a workflow.graded_count < 3.  This is additional meta data that is included each time an assessment is saved. By filtering this before we do the count at the end, we immediately avoid grouping the submissions that have enough grades.

Furthermore, the count() is only expensive so long as there are an extremely large number of assessments; this since the number of 'completed' workflows will increase as the number of workflow items increases, we should stabilize on performance in a real scenario. 

So I imagine the big question is, what about when there's 30,000 workflows that are not completed, and have not been assessed?  The count should be minimal; the count(pwi.id) should be relative to the number of PeerWorkflowItems created; this means the flat state is cheap, and as the PeerWorkflowItems grow, the PeerWorkflows will shrink.

So I think I'm ready to run another load test.