Trivial fix to move int declaration to top because Android gcc defaults to C89 mode instead of C99.
Added #include <stdint.h> because the existing attempt to define if needed is causing redefinition errors in our complex project involving both pure C and C++ code.
Lowered bufferCount in OpenSL ES implementation from 8 to 4 because the base case latency of playing a single sound was terrible/worse than the Audiotrack version (which already contained my latency tweaks from the Martins Mozelko branch).

Lowering this value may negatively affect the mixing throughput for lots of sources. But this is a balancing act to not make the latency worse than the Audiotrack backend.

I tested on Kindle Fire (2.3), Nexus 7 (4.1), Motorola Xoom (3.?), Galaxy SII (2.3.4). In all cases, the latency seems to be about on par with the Audiotrack backend. Somewhat more subjective, the OpenSL ES backend with this change sounded a little cleaner to me.

I picked 4 somewhat arbitrarily. Being burned by non-power-of-two things before, I liked going from 4 to 8 and the latency improved to where I wanted it.

The latency is not really noticable on the Nexus 7 running 4.1 regardless of this change. This suggests a future fix dynamically change this constant back to 8 if running on 4.1+ if the Apportable values were well picked/tested to begin with.
Modified OpenSL ES backend to dynamically set the bufferCount based on the current Android OS version (at runtime). My previous change to lower it from 8 to 4 did in fact give us reports that Android 4.1 playback was breaking up. Marc Salem did warn me that this was a possibility because the 4.1 timing characteristics/requirements changed drastically. So the change is to check for the current OS version and set the bufferCount to 8 if >=4.1 and 4 if below 4.1.

One tricky modification is that JNI is needed in the opensles.c backend which impacts a function pointer previously not being set and is sensitive to initialization order. This changes the logic slightly to ensure initialization is correct and not overwritten by AudioTrack initialization.

Thanks to Josh Quick for help on the JNI code to get the Android API version number.
Moved CreateAudioPlayer related block from opensl_open_playback() to opensl_reset_playback(). This is to fix/properly support ALC_FREQUENCY. The problem is that if you set the frequency to say 22050, the playback is too fast (chipmunk). I believe this is because OpenAL Soft is changing its rate, but the OpenSL backend does not causing the mismatch.

The first problem in the OpenSL backend is that it hard codes the frequency to 44kHz.
The second problem is that the OpenSL backend initializes the player too early. I believe it is initializing at the device opening, and not the context creation where the ALC_FREQUENCY parameter is set/bound to.

So the solution is to move the CreateAudioPlayer stuff to this section which seems to be the reset_callback and respect the Frequency parameter passed through to the callback. I compared to the current mainline OpenAL Soft/OpenSL backend and their implementation seems to place the audio player creation in this same place so this at least makes this implementation more consistent with the official one.

This implementation does suggest to me that it doesn't handle multiple contexts well/correctly, but that is a problem independent of this fix.
Fixed issue where closing and then re-opening the audiotrack (Android 2.2 and below) would not reset the suspended state back to false/zero.
Fixed resume to block until the audio thread is ready.