[omx] Restrict the number of outstanding jpeg calls to gpu

Allowing more than one outstanding call to gpu for texture encode/decode can be beneficial as processing
can be overlapped with vchiq message transfer.

Experimentally, 3 outstanding operations is optimal.

Allowing more that this ties up memory on GPU without any performance benefit, so avoid submitting more jobs
[videodb] Refactor CVideoDatabase::GetValueString into ProcessValueString, GetValueString
[videodb] Initial work on fine-grained DB updates for Movies

Lots of new code here, most of this is from a post on forums:
Things to do:
A few bits of tidy up refactoring, eg CVideoDatabase::GetValueString's 2
versions could do with their core being merged.
Style/whitespace probably isn't quite right
Some of the funcs could probably do with better names
Some docs on how the Update works, as it's rather tied into being called
from JSON
Testing - at the moment I've done some basic testing, but really need to
check that the api works in all cases.

Note the focus is for the available calls from the JSON VideoLibrary.

How does it work:
During the parsing in UpdateVideoTag of the JSON items into the existing
object, a vector of changed items is made.

To try and make the code more readable I've converted the long list of
If's into calls to new wrapper funcs (also called UpdateVideoTag) The
simple wrappers checks that the current value is differnt to the new
value, and only flags it for update, complex lists are always updated.

I'm not happy with how many versions of UpdateVideoTag there are, I
can't escape the feeling some kind of generic would be better, however,
there's no generic conversion on CVariant.

The idea is that the JSON provides the vector of changes into a new API
in the VideoDatabase code.

The new API is called:
UpdateDetailsForMovie

It takes the same params as SetDetailsForMovie, along with the vector of
changes.

The first it does it take the vector and convert it into two lists,
handled by PendingUpdates.

One is a list of the simple changes (in fact a list of VIDEODB_ID enum
values).  This list is checked for types that I guess have changed into
lists, eg genre, directors, although they were once their own field in
the db.  This simple list is used to create the UPDATE SQL call.

The more complex list contains harder to parse items, eg art and tags.

If it doesn't understand one of the changes it falls back to using the
SetDetailsForMovie.

The update work then tries to only do the needed updates.  It starts
with the simple updates, and processes the lists, eg Genre, director,
studios, and deletes the db entries and adds them back in.

It them moves onto the tags and art, and processes them in the same way,
IE only deletes them if needed.

The last part is the SQL Update.  I've added a new version of
GetValueString, which takes the vector of "simple" changes, and will
generate an update of just the items that have changed.

If nothing needs an "UPDATE" one won't be run.

Some code tidy-up before pull request

Fix build failure.
Fix some indentation issues.
Remove some comments/notes to myself.
Merge some CStdString and the = PrepareSql lines.

Fix Log message

Correctly pass log message a char * rather than std::string.
Possible fix for performance issue on updates

If 300+ updates are carried out too quickly then the message loop
struggles with the refresh events from the Json layer.

It appears that the JSON layer triggers a full refresh, and this causes
pain if you're on the movies view as the refreshes process.

I've added an extra API to allow a FileItem to passed into the refresh
builder, and it then passes that item around as being the thing to
refresh.

This stops the heavy refresh rate, but still slows the UI down while it
gets through the backlog of events.

I've also added code to only push a refresh event if there was actually
a change to the movie.