adapt interface in libcvmfs.h for multi-repo support
Refactor: option parsing for multiple option sets
multiple repo support in libcvmfs.cc
expose `cvmfs_attach_repo()` in libcvmfs.a
elimiate globals in libcvmfs_int as much as possible
FIX: compile error in usage()
allow multiple (CERN) repos in test_libcvmfs
add LIBCVMFS_VERSION macro
add alien_cache config parameter
FIX: call quota::Spawn()
refactor cvmfs_fini() and cvmfs_detach_repo()
adapt test_libcvmfs.cc
move LruCache<> fields to central location
make allocator in LruCache<> non-static
amend re-engineering notes
adapt usage() text
Merge pull request #502 from reneme/feature-multi_repo_libcvmfs

Feature: Multi Repository Support for libcvmfs

This does adaptions to libcvmfs to quickly (and reliably) switch between different cvmfs repositories. Some more details can be found in the corresponding Pull Request in the cctools project.

To make it work some interface changes to libcvmfs were inevitable. Essentially as much of the global state in libcvmfs as possible was eliminated by separating global from repository specific functionality. Hence, all ‘mounted’ repositories share one cache directory that is configured before initialising any repository making the configuration two-staged.

Users are now supposed to call cvmfs_init() with global options related to the caching and logging behaviour of libcvmfs. Afterwards one needs to call cvmfs_attach_repo() with the remaining repository specific configuration. This function will return a cvmfs_context* that needs to be passed along all the other libcvmfs function calls.

lru.h was using a global memory allocator whose state got screwed up when used by more than one repository. I removed the overridden new and delete operators (that were dependent on global state) and replaced it by a more STL-like approach with Construct() and Destruct() methods. Construct() allocates memory and uses a placement new and copy constructor to create an object whereas Destruct() calls an object's destructor explicitly and deallocates its memory region afterwards. The adapted allocator is now local to the individual LruCache<> instances and does not expose any global state anymore.