some efficiency issues

[mtholder]

None of these are high priority, but we could make things snappier by:

1. paginating the find_studies call that fills the curator front page. It's getting pretty big (33M)
2. storing the output of otindex's find_studies and modifying it in memory as studies get edited. Obviously this would be more of a pain.
3. storing the find_collections output and modifying it in memory (as in 2, but for collections)
4. adding a without_version_history call for getting a study and then loading the version history of a study asynchronously through a separate call. Same total time (or worse) for the curator. But the history tab could lag. We are committed to adding the history by default at least in version 3 of the APIs, but it does add a fair amount of extra work for something that not all users want/need.