Enable SQLite to use mmap for file access.

The time it takes to issue "SELECT * FROM tvshowview" (the first time the
TV Shows library is opened) with 345 TV shows on a non-overclocked
Raspberry Pi changed as follows. Times are in seconds:

      Before          After
      Mean   StdDev   Mean   StdDev  Confidence  Change
Time  3.352  0.132    2.550  0.021   100.0%      +31.5%

These times assume SQLite has already been upgraded to version 3080301
(see PR #4235).
Pre-populate the mmap'ed database file in SQLite.

The time taken to issue "SELECT * FROM tvshowview" in seconds improves
still further in this case.

      Before          After
      Mean   StdDev   Mean   StdDev  Confidence  Change
Time  2.550  0.021    2.375  0.043   100.0%      +7.4%

Note, this requires the standard SQLite amalgamation tarball to be patched
prior to building. The change may not be desirable further upstream due to
the fact that it might cause database access times to increase in usage
scenarios that differ from those employed by XBMC.
Fix memory leakage in python bindings

The python bindings generated by the groovy code generator contain a reference counting bug which results in a memory leak whenever a std::vector is converted to a python list.  The following member functions are affected:

* xbmcvfs.listdir
* xbmc.Player.getAvailableSubtitleStreams
* xbmc.Player.getAvailableAudioStreams
* xbmcgui.Control.getPosition
* xbmcgui.Dialog.browse
* xbmcgui.Dialog.browseMultiple

The reference counting bug occurs because PyList_Append() increments the reference count of the item, so the caller needs to call Py_DECREF() because it no longer owns the object.

This bug is especially problematic when running the Watchdog Service Addon since it may result in frequent calls to xbmcvfs.listdir, and each call can leak many kilobytes of data when listing directories containing many files.
allow fallback to root menu call if title menu call fails (like VLC)
allow to return from "endless" loop of NOPs
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.
Reapply change that was accidently undone

In the process of setting up the fork, I copied my changed files, and
missed that change 43a62fe36b4530c07efb8c6aa7dbdcf7c406af63 hadn't been
applied.

Reapply that change to fix incorrect query which includes idActors
Update VideoLibrary based on comments from GitHub. Basically sprinkle some const, and rename the functions and the fieldValue.
Remove c++ 11 cbegin and cend

Fix compiler errors/warnings for non c++ 11 compilers.
Short cut the case of there being no updates to process

If updateDetails is empty return the movie Id.

While the code won't run any SQL, it saves Transacting nothing.
Further performance improvements for updates.

Split artwork changes into altered and removed.

Add some log messages to allow for better timing.

In SetArtForItem only update an item of art if the url has actually
changed.  Saves a number of extra round trips.

Remove code that set the lastplayed and playcount to match any other
found copy of the movie.  It doesn't seem to make sense to do so during
an update, as the update requires the file already exists, so it's not a
new file.
Refactor CVideoDatabase::GetValueString

Both functions now call a common routine to process the value string.

Also correct a missing pass by reference on the newer version of
GetValueString.
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.
Flip some && tests to do the cheap part first

IsXXXDb calls are expensive as they build a CURL object.  While the
HasXXXInfoTag is a cheap != null test.

So do the cheap tests first.  Reduces some of the overhead of the
IsSamePath code.
Another optimization to IsSamePath

If both items have video info tags then if it's the same movie and file
id it's the same path.
Use URIUtils version of Is{music|video}Db

Update CFileItem IsVideoDb and IsMusicDb to use the URIUtils version.

The URIUtils version should be good enough.  Note that it doesn't
actually parse the URL though, it just string compares the beginning of
it.
Should be performance gain for anywhere hitting this code.