Allow custom batching implementations.

[jamestalmage]

I find myself wanting more control over how things get batched in angularFire.
This introduces a batchingFactory config option that allows substitution of the default implementation.
Going forward I see adding finer grained control by allowing different strategies for $save,$update, etc.

A common use would be blocking/canceling pending updates from the server if there is a local change pending.

[coveralls]

Changes Unknown when pulling c51e6be on jamestalmage:custom-batching into * on firebase:master*.

[katowulf]

We've talked about pause/resume type functionality before. This is an interesting concept and probably not too hard to implement. My primary hesitation has been that it's a complex feature and would likely be abused and confused by users who are not extremely well versed in Angular and async behaviors.

It also seems like much of this functionality could be obtained by overriding $$process or the specific $$added et al. Let me ponder and chat with @jwngr about this.

[jamestalmage]

My concern with $$process, $$added, etc, is that batching is a cross-cutting concern that will likely apply across multiple object types, so implementing there is going to lend itself to repetitive code. Also, it would force users to deal with batching just to override those methods (and as you've said, that is asking a bit much of users who are just starting out with angularFire).

[jamestalmage]

This way allows users to leverage a sensible default batching mechanism we provide, and override it if they need to. We could also provide a simple option to disable batching altogether.

[katowulf]

To clarify, I feel like pause/resume and batching are different concepts, and my comments above would only apply if we replaced our batching with the $evalAsync approach.

[katowulf]

After we release 0.9.1, I'm going to investigate $evalAsync and probably remove batching.

[jwngr]

Closing this PR in favor of #411.