Be more consistent and consider PSR-0 conventions in 3rdparty module loading, add manifests

This change should introduce more consistency and clarity into the use of 3rdparty includes. This PR makes the change for the 3rdparty stuff in core/apps/*/3rdparty; I'm planning to send a corresponding change for the 3rdparty repo which contains all the 'project-wide' 3rdparty stuff.

The high-level approach here for 3rdparty modules that are PSR-0 compliant from some position in their directory hierarchy is to have apps that want to require files from them add that PSR-0 top level to the PHP include path, and then require the PSR-0 style relative path from there. Previously, there was a mishmash of apps that did this, apps that added a more nested path to the include path and then used very short relative requires, and apps that weren't using the include path at all but just hardcoding the location of the file in the Owncloud tree somehow or other.

For 3rdparty modules that aren't PSR-0 compliant, I tried to set it up to match how downstream distributions lay out the same modules. For instance, Fedora's php-opencloud package (currently under review) will provide the same tree under /usr/share/php/php-opencloud as Owncloud provides under apps/files_external/3rdparty/php-opencloud - so I set the app that wants to use it to add the 3rdparty directory to the include path, and then require php-opencloud/(whatever). This will work properly both for upstream and for downstream distros that lay things out the same way as Owncloud does. A reasonable convention for both Owncloud and distros is to preserve the directory structure of upstream's preferred distribution format underneath a directory that's in the include path (/usr/share/php for distros, blahblah/3rdparty for OC), and then use relative paths from there when manually requiring files.

The MANIFEST files contain all the information I always *wish* webapps would include about what 3rdparty bits they're bundling: what they all are, where they come from, what files are part of what modules, what versions they've included, licenses, and notes on how they've been modified downstream. It's a gigantic PITA for downstream distributors when this information is not included. The work to relocate things in this PR was actually trivial and took about 20 minutes; the work on the MANIFEST file has taken me about four hours. I invented the format as I went along, if anyone's aware of a standard or convention relating to providing this kind of information I'm happy to change the format, but it's really important for downstreams that the information be available.