Sync Fitbit data from the present backwards

WIP: haven't tested yet.
Fix Fitbit devices not updating sync time

Our synclet config management does a merge and only needs the updated data from
a synclet. Because each synclet was returning the full config before, non-device
synclets were overwriting the new sync time that the device synclet just set.
Fix Fitbit synclets clobbering others' windows

The top-level `sync` object was being clobbered just like device sync times
were, because each synclet would return others' data. Moving each synclet's sync
status to its own top-level object avoids that and readies us to run them in
parallel.
Allow shared state across parallel synclets

Now we can prefix special config variables with `_` and they'll get hoisted into
the global config space. During sandboxing, any `_var`s are included in the
synclet namespace, and when the synclet returns a new config, `_var`s are merged
back into the top-level config object.

This allows us to communicate between synclets that somehow depend on each
other. Fitbit, for example, needs to pass the last device sync time to the rest
of the synclets so they know how far to fetch data.

Now, the config looks like:

```
{
  synclet1: {...},
  synclet2: {...},
  _shared1: ...,
  _shared2: ...
}
```

This obviously reintroduces the danger of synclets clobbering each other's data,
so we must do our best to isolate writing of a given variable to one synclet and
leave the rest only to read. If it becomes necessary, we can give each synclet a
writeable section that it made available to other synclets, but ignores their
changes to it. Convention should do for now.
Lint taskman

- ===
- Semicolons
- Line length
- Shorten curlies
Run Fitbit synclets in parallel

This uses the new shared variables to pass the member join date and latest
device sync times into the rest of the synclets.
Make all synclet config available read-only

Via @smurthas, this is much simpler, safer and useful than the `_`-tagging
method. Now each synclet gets its own configuration in `pi.config` and access to
everyone else's in `pi.all.*`. When it returns a `config` object, it can only
update its own.
Use the new sharing pattern in the Fitbit synclets

Now the data synclets can all see the device sync time straight from its
synclet. We can also do away with the `_device_ran` flag, because with the
sandboxing we know it ran when its config appears.
pull new connections in linkedin network synclet.

use the /people/id=abcdefg endpoint to get new connection info right away
inside of the network synclet instead of waiting for the connections synclet
to run. the connections synclets was going over the rate limit with fresh=true
because it has a 20k/app/day throttle limit.

Still need a way to be able to specify fresh=true for connections without
it having to run the connections endpoint. that will be next!
Simplify read-only config passing

The swap variable came out organically but wasn't needed - this is easier to
understand. Good catch, @smurthas.
Merge pull request #614 from Singly/reverse-fitbit-sync

Parallelize Fitbit and sync from now -> backwards
Remove underscore dependency

Ended up not used
fix a nasty linkedin hard loop when conn > 500.
Merge branch 'master' into linked-throttle--
Merge pull request #617 from Singly/linked-throttle--

LinkedIn Connections Throttle Limit Improvement
allow synclets to specify a freshInstead.

Used right now for LinkedIn Connections, so that when `fresh=true` is passed to
`/services/linkedin/connections` it runs the network synclet instead of the
connections synclet (network gets the latest connections and avoids rate limits)
Merge pull request #621 from Singly/linked-fresh-throttle--

More LinkedIn Connections throttling improvements
only show the last run time if there is a tdone.

if a synclet had never run, dawg used to always now that the last run was
  "a few seconds ago" which was quite confusing!
Merge branch 'master' of github.com:Singly/hallway into friends