Bug 1023664 - Calendar recurring events r=millermedeiros

### Current status (as of 08-21-2014)

There are still (at least) three noticeable regressions

1. All busytime dots aren't being loaded (at first) into the month view. They do get loaded after swiping a month out of memory and then swiping it back in though. This is probably related to changes to `provider#ensureRecurrencesExpanded`
2. Clicking the settings toggle is _very_ slow. Need to debug to find root cause.
3. Modify event time selector is borked?

### File by file (as of the morning of 08-20-2014)

#### index.html
+ Load lodash.js
+ Load calendar helper functions which have been moved out of `calendar.js`

#### .jshintrc

We had a lot of calendar-specific globals which should be removed eventually and (in the meantime) declared on a per-file basis.

#### app.js

Overall cleanup for modularization, migration onto new provider api. Move offline helper into its own module.

#### binsearch.js

Moved out of `calendar.js`

#### caldav_worker.js

+ Load calendar helper functions which have been moved out of `calendar.js`

#### calendar.js

Before this was a grab bag of functions. They've been moved into their own modules. Yay!

#### compare.js

Moved out of `calendar.js`

#### recurring_events.js

+ General refactor
+ Migration to new provider api

#### sync_controller.js

+ General refactor
+ Consume online detection from new module instead of function on app

#### date_l10n.js

Moved off of `calendar.js`

#### db.js

+ General refactor
+ Add migration for creating ical components for pre-existing events

#### extend.js

Moved off of `calendar.js`

#### format.js

Small cleanup

#### load_config.js

Update with provider changes

#### log.js

Moved off of `calendar.js`

#### next_tick.js

Moved off of `calendar.js`

#### ns.js

Moved off of `calendar.js`

#### object.js

Miscellaneous object methods like `map`, `filter`, and `forEach`... could be replaced by mout/lodash/whatever

#### online.js

Moved off of `app.js`

#### pending_manager.js

Moved off of `calendar.js`

#### performance.js

Module-style cleanup

#### probably_parse_int.js

Moved off of `calendar.js`

#### promise.js

Module-style cleanup

#### provider/

Get rid of local/caldav inheritance. Move lots of local methods to use caldav service without syncing (for ical operations).

#### responder.js

Module-style cleanup

#### retry.js

Created to abstract retry pattern used in `recurring_events.js`

#### service/caldav.js

Make server sync after things like `createEvent` optional.

#### store/abstract.js

+ Fix denodeified all function
+ Remove duplicate `probablyParseInt`

#### store/calendar.js

+ Fix denodeified all function
+ Remove duplicate `probablyParseInt`

#### store/event.js

No more `#providerFor`... there is only one provider to rule them all!

#### templates/calendar.js

+ Fix denodeified all function
+ Remove duplicate `probablyParseInt`

#### views/

+ General refactor
+ Migration to new provider api

### Change Summary

#### Functional
+ Create a database migration to create ical blobs for existing, pre-2.1, local events
+ Merge the code paths for `provider.ensureRecurrencesExpanded`, `provider.createEvent`, `provider.updateEvent`, and `provider.updateEvent`
+ Pass flags to the CRUD methods in the caldav worker to indicate whether or not changes need to be persisted to a remote server (since they're now also handling local events)

#### Stylistic
+ Move `Provider.Local` and `Provider.Caldav` into the same module since much of their behaviors are converging here
+ Move offline detection into a separate module
+ Node-style callbacks turned into promises
+ Since we'll only ever have a single instance of the provider(s) running, it shouldn't be an instantiable class (for simplicity like Miller and I talked about)
+ Cleaner abstractions in the provider where we're doing things like streaming things from the caldav worker into the stores (ie `createCaldavStream`, `consumeCaldavStream`, and `pipeToStore`)

### On the way

+ Handling for creating, editing, and deleting occurrences
+ High-level unit tests which will setup the provider, service, stores, and radicale server and then make sure that calling various methods on the provider injects the right things into the stores
I just did not understand why you decided to put the `provider.app` and `exports.provider` logic here, instead of inside the method `_init` or inside `configure`..