upating karma.conf.js to reflect current state of spec fixes

I messed around a lot. These kind of things that happen when
you're in the CheeseCakeZone™. For like 25 hours.

Anyway, here are the things that I still remember I did:

1. Removed any kind of inheritance. Instead I made a storeApi
   module that is configurable and can pass an `options.backend`
   hash of methods to hook into the actual storage. Required
   methods are `save`, `find`, `findAll`, `remove`  and `removeAll`.
   You can also pass a custom validation method with
   `options.validate`. So this way, the `backend.*` methods get
   can be sure that they get only valid parameters passed,
   validation has been taken care of, and the modules like
   `localStore` and `remoteStore` can focus on the actual
   persistance layer, without overwriting any of the core API.
   It actually feels good, I'm sure it could use some more cleanup
   and certainly some more specs need to be fixed. But lots of
   code could be thrown away.
2. The `hoodieRemote` module, the custome `remoteStore` for the
   user database that used to be it's own module inheriting from
   `remoteStore` is no more. It is just a simple
   `hoodie.open(userDbName, options)` plus a few event bindings.
   I like this a lot as it clears up a lot of unnecessary code
   and it works as a proof of concept that other developers can
   do similar when building plugins, like the share plugin that
   currently depends heavily on custom remote store behavior.
3. I moved or tried to move out side effects / initializations
   out of the modules and into the Hoodie Constructor. I'm not
   sure if that doesn't become to staffed now, I also did a weird
   hack with methods that do get exposed but then remove
   themselves after the first execution,
   `hoodieStore#bootstrapDirtyObjects`. Let me know what you think.

And last but not least, I found a reason that might actually
argue against a simple `new Hoodie` constructor: it's not async.
That doesn't hurt at the moment and I wouldn't worry about it,
but it's something I'll keep in mind. For example, the
`hoodie.config` has a sync API for simplicity reasons, but therefore
nees to initialize it's cache on startup, which it does with

    hoodie.store.find(type, id).done(function(obj) {
      cache = obj;
    });

That works because currently the `hoodie.store` API uses
localStorage under the hood which is sync, but that might change
in the future.

Anyway, that's so far from my side.

Robin, a Berlin-based freelance dev, loves open source, programming &
organizing events. He's excited to see the promising future of web
development with tools like Hoodie. Robin is always looking for
interesting new projects: http://go.hood.ie/coding-robin