Speed improvement for opening the movies library

On all but the first time of opening the movies library, the CFileItemList
is built using CArchive. A large proportion of the time taken to do this is
actually spent in CVideoInfoTag::Archive() where it calls
CScraperUrl::Parse() and CFanart::Unpack(). Unless I've overlooked something,
these calls are unnecessary - the XML parsing they do is not performed the
first time the movies library is opened (when instead the virtual directory
videodb://movies/titles/ is enumerated using a database query). Also, the
Parse() method is called again when you do something like open the Movie
Information window, irrespective of whether it was called when the library
was opened.

Also note, it is unusual for any implementation of IArchivable::Archive() to
do anything other than read or write a data member from/to a CArchive, so
these calls to Parse() and Unpack() feel like an anomaly.

Additionally, inserted a call to std::vector::reserve() before reading the
cast list, because it was an obvious speed win.

Here are some benchmarks for the function CGUIMediaWindow::GetDirectory()
on a library of 600 movies, running on a Raspberry Pi:
* First call (before or after):    3.4 seconds
* Subsequent calls (before patch): 7.3 seconds
* Subsequent calls (after patch):  2.9 seconds
Revert "[depends] - fix target config site script. It wants to set LD_LIBRARY_PATH to the deps dir not to the native buildtools. Found when trying to get ffmpeg gnutls to work. On osx ffmpeg tried to pull in libz from native dir instead of system toolchain because ld_library_path was set wrong"
after talking with theuni i just got it wrong and it was indee correct before.

This reverts commit f02e456f996cc44a18e15c95e53bfa9471e40a7c.
filesystem: fixup redirected exists checks (they would never return true)
CFile: some cosmetics
Merge pull request #3233 from bavison/faster_videoinfotag_archive

Speed improvement for opening the movies library
[cosmetic] rename non-member var