Add sessionStorage based scroll memory for Dartdoc's scrolling divs

[jcollins-g]

Fixes #1915, #1288, #1372, #779, #1870 and probably a host of other complaints in other repositories about Dartdoc's suboptimal scrolling behavior.

Use sessionStorage connected to some JavaScript that saves and restores positions for all three of Dartdoc's scrolling divs. We start with all three divs visibility: hidden and only display them after any restorative scrolling has occurred, so the page loading is seamless.

My Javascript is extremely primitive (since I don't actually know JavaScript) but seems to work for local browsing, including @Hixie's case of multiple tabs with the same page but different scroll positions.

[coveralls]

Coverage remained the same at 93.966% when pulling 1659ded on style-refresh+javascript-scroll-memory into 2aa6060 on master.

[Hixie]

This is great!

One suggestion: We should use sessionStorage rather that localStorage. That way, if you open two tabs on the same page, then navigate both, then return from both, it'll work correctly.

[jcollins-g]

It was unclear to me that the definition of a session included being able to navigate away from a page (though it makes sense now that I think about it). I will try using sessionStorage. I can discard lscache if that works, as there won't be a need to avoid collisions between different URIs then.

[jcollins-g]

@Hixie Indeed that both works better and simplifies the implementation.

PTAL.

[devoncarew]

One small concern, but I don't have any better alternatives, and it's likely not a real issue.

[devoncarew]

This all looks correct, but I can't help but wonder if there are places where this could fall off the rails. If you javascript script didn't run, or threw an exceptions for some reason before it could restore visibility?

[jcollins-g]

Yes, this is a risk. If the javascript doesn't run due to an exception, the screen becomes blank (indeed, I experienced this when writing the code and accidentally introducing bugs).

The only thing I can think of to reduce that risk is to wrap all our JavaScript in the try of a try/finally with the visibility switch-on occurring in the finally block.

[jcollins-g]

I've wrapped the restore part that can be wrapped in a try-finally block, and moved it ahead of all the other javascript initialization. This means the page visibly appears slightly faster and should be more resilient to exceptions.