[rbp/omxplayer] Avoid submitting too large audio buffers

The audio_decode output port buffers are 32K and we want to ensure our packets fit in these.
Audio decode produces samples of 16 bits and rounds the channels up to the next power of two.
We need to calculate the largest input packet size for the given bpp and channels and limit submitted buffers to this.

This has been observed to cause no audio output with wma audio.
[rbp/omxplayer] Fix bugs with jpeg parsing

I was finding GetCodingType to sometimes take 200ms for a single jpeg.
That was a mixture of the slow bit oriented parsing, and more significantly some bugs.
The SOF blocks skipped the wrong number of bytes, meaning we ended up parsing junk.
The M_TEM, M_DRI, M_SOI and M_EOI tags when seen (usually due to the junk) can only escape by slowly parsing until end of file.
Also, after a M_SOS, there is the variable sized jpeg block which we can't parse, so best to give up then, rather than misparsing the jpeg data
VideoRenerers: add buffering
add buffering for GLES
WinRenderer: add buffering
DXVA: activate buffering in renderer
linuxrenderer: delete all textures on reconfigure
drop frame counter in application, ask render manager instead
vaapi: adopt to buffering in renderer
add buffering - some documentation
RenderManager: only flip free buffer if player has added something
move NUM_BUFFERS up to BaseRenderer.h
OverlayRenderer: align buffers with index in renderManager
add buffering - submit absolute time to render buffers
RenderManager: some rework, squash add buffering
dvdplayer: disable buffering unil dropping is improved
RenderManager: skip very late frames in render buffer
renderbuffers: drop enable/disable in this iteration
RenderManager: add method SetSpeed
OMXPlayer: adapt to buffering