Improve performance of history timeslicing

[the-hobbes]

Although we now retrieve an accurate amount of items from the history api with the inclusion of the maxResults parameter in the api call, the amount of results we are retrieving is causing performance issues. We need a way to mitigate these issues. Ideas include:

• loading a years worth of data immediately and using that as a cache to slice from
• limiting the amount of items returned by maxResults
• starting at a day's worth of data, and loading a larger set in the background into a cache so that further slicing can be performed on it as needed, without api calls.
• adding a loading gif to make the wait times seem shorter

[the-hobbes]

Testing show that:

API retrieval took: 18.58199998969212 milliseconds. Visit processing took: 22.45500002754852 milliseconds.

[the-hobbes]

I want to avoid having to call buildHistoryItemList() each time the timeslice is changed.

[the-hobbes]

Also, investigate possible performance increases by not creating li nodes for each item and using regex instead, as well as optimizing the code.

[the-hobbes]

Seems to be somewhat improved now. I'm sure we can get better, but I'd like to keep the fact that it updates instantaneously, which would be hard to do if we weren't fetching the entire updated chrome history each time.