Have 3rdparty directories act as PSR-0 compliant namespaces

This moves PSR-0 compliant 3rdparty modules - Crypt_Blowfish in
files_encryption, and phpseclib and smb4php in files_external -
such that these directories represent a PSR-0 compliant namespace
for those PSR-0 compliant modules. Dropbox in files_external
already happened to be perfectly PSR-0 compliant.

It adjusts the apps that use these modules to load them in a
compatible way, by adding the 3rdparty/ directory to the
include_path and then requiring the PSR-0 compliant relative path
from there. In theory, we could make the OC class loader do
autoloading for these modules and drop the need for apps to
explicitly require things at all, as a follow-up.

This makes consistency between upstream and downstream
distributors who unbundle modules much easier, as well as
providing the autoloader possibility. As long as downstream
distributors package PSR-0 compliant modules properly, they can
just remove the bundled copies from OwnCloud and rely on apps
being able to find the system wide copies, since everything is
using the same conventions.

I did not include aws-sdk-php in this commit due to the fact that
it has bundles inside of bundles; I worried it would trigger an
argument about whether perhaps some other part of files_external
might want to use some other version of Doctrine or Guzzle or
Monolog or Symfony. In fact, if we moved the bundled subsets of
Doctrine and Symfony to be PSR-0 compliant inside
files_external/3rdparty, we'd introduce an interesting question
as to whether files_external would wind up loading aws-sdk-php's
copy of Doctrine and Symfony, or the ones in OC's main 3rdparty/
directory...if this general approach is approved, I'll tackle that
mess as a follow up.