Bug 1023664 - Calendar recurring events r=millermedeiros

### 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 find it really weird that we are manipulating the `params` multiple times... when we call `request` we have to figure out the order and here it adds even more data.. I think we should change this logic into something like this:

```js
request('createEvent', {
  account: account,
  calendar: calendar,
  event: event,
  busytime: busytime,
  owners: owners
});
```

and we add the `details` and the `sync` properties dynamically inside the `request`:

```js
function request(method, data) {
  // ... omitted the local provider behavior for brevity
  data.sync = !isLocal;
  // pass a single object as argument
  return worker[method](data);
```