Use bounded ThreadPoolExecutor for async notify calls

[felipecsl]

We noticed performance issues when making several calls to Bugsnag#notify in a short period of time. It turns out that it's because it is using Executors#newCachedThreadPool which creates as many new threads as needed. This can quickly overload the system, cause lots of GC overhead and even ANRs.
Just used the AsyncTask#THREAD_POOL_EXECUTOR settings here and made it a tiny bit more conservative.
Also updated the dependencies while I was at it for convenience, but if you don't want that in this PR, I'd be happy to revert them.

[kattrali]

Thank you for the contribution, @felipecsl. I'm investigating what's happening with the tests now, as the tasks which start runnables now encounter a VerifyError during initialization.

[kattrali]

This seems to be an issue with calling allowCoreThreadTimeOut(boolean), despite the code being gated by SDK version. Without it, the tests then pass as expected on API 4 and newer.

At runtime, the verifier rejects the Async class because the method cannot be found:

E/dalvikvm( 1091): Could not find method java.util.concurrent.ThreadPoolExecutor.allowCoreThreadTimeOut, referenced from method com.bugsnag.android.Async.<clinit>
W/dalvikvm( 1091): VFY: unable to resolve virtual method 717: Ljava/util/concurrent/ThreadPoolExecutor;.allowCoreThreadTimeOut (Z)V
W/dalvikvm( 1091): VFY:  rejecting opcode 0x6e at 0x0049
W/dalvikvm( 1091): VFY:  rejected Lcom/bugsnag/android/Async;.<clinit> ()V
W/dalvikvm( 1091): Verifier rejected class Lcom/bugsnag/android/Async;

Did you see similar improvements to performance even without timing out the core threads? There could potentially be less core threads while keeping the maximum as well, though that would be more aggressive.

[felipecsl]

Yeah it should be fine to remove that since it's a minor optimization.
I'll update the PR

[felipecsl]

PR updated, @kattrali PTAL