Improvements to Extension handling

At the meeting with @ricci, @hibler, @gtw, and @duerig we discussed improvements to extension handling. This is more or less a summary of how I remember it, please add your own comments or fixes.

First off, Rob mentioned a few goals.

Vary the automated extension based on node usage, demand for nodes of the request type, idleness of the users nodes, etc. For example, moonshots are typically underutilized so we should be granting longer auto extensions for people using them.
On the extensions page, change thresholds along the slider based on the number of nodes being requested and the length of the extension. For example, it should be easier to get an extension for a single node for a week, then 10 nodes for a week.
Collect historical idle data at the clusters (using existing slothd capability) and factor that into extension requests, both in the automated extensions, and on the admin extension page. Initially we just show users, but then we start using the data to push back on users, and then later, integrate into automated extension.
Idleness data needs to reflect not just instantaneous idleness, but idleness over time, perhaps as a bar graph of when nodes are in use or idle over the last N days.
On the user extension page, tell users how they rank against other users in their usage. Ditto for projects. This needs fleshing out!
Add cluster utilization to the admin dashboard page. I did a quick cut of this in my devel tree, but I am not all that happy with it. I think we need to break it out by type, but not sure how to display that in a compact manner.
Later, Rob and I discussed a new extension helper page, that would be contain various bits of data that would be used to make the admin decision. Rob does want to have to open 5 different pages, but wants all of the collected data mentioned above, in one place wrt the experiment being considered.

Anything else?