Creates abstract DataReloader runnable to hold data-loading code.

First step: recognizing that the ProjectDataReloader is not the right
place to put the knowledge for:
* how to load login status
* how to load project details
* how to load last update times

The fix is to create a class to hold that knowledge.  Just did one of
the three, for clarity's sake.
Repeats the previous refactor for the other two data types.

Two nice benefits already:
* No more "how to load" logic in the ProjectDataLoader class
* no more inline implementations of Runnable

Next up, we tackle the repeated logic in the concrete subtypes of
ProjectDataLoader.
Factors "whether to reload" logic into a "reload policy" class

There was a lot of logic that should have seemed repetitive and
suspiciously similar around the question "should I reload this data type
on this round of reloading?"

By pulling that logic into a named class, we remove a lot of
opportunities for typos in the conditionals, and introduce one place in
which that logic can be changed in the future....
Removes concrete subtypes of ProjectDataReloader.

The Static and Live project data reloaders were starting to seem pretty
thin -- not enough logic in them to justify their existence!  So we
favor composition over inheritance and making it so different project
reloaders HAVE different data reloaders.

This is a key benefit of adding the DataReloader class.
Streamlines reloading logic to use ScheduledExecutorService

The next big red flag to tackle was the huge loop logic in the
ProjectDataReloader. If you have to handle periodically repeating tasks
that are run in Threads, it's a pretty sure bet that Java's executor
classes have done it better already.

After this refactor, all work of scheduling is done by the
ScheduledExecutorService, and the ProjectDataReloader is only looping in
order to stop.


In order to take advantage of the data structure, we needed to be able
to express our reload policies in terms of time, not "reload counts."
Remember that thing where I said that having the "reload policy" would
give us one place to change the logic around reloading?  This is where
that pays off.

Removed the reloadsCounter altogether, since we don't care anymore.
Eliminates all Threads, waits, and looping from ProjectDataReloader.

The final step is to simplify the start() and stop() methods of the PDR
class by holding on to the ScheduledExecutorService instead of the
"stopped" boolean.  By surfacing the former, we can perform the shutdown
in the stop() method.

That way, there's no need to listen for/care about the concept of
"stopping" in the start() method.

Also tightened visibility and removed now-unnecessary class members.