Use a standard for class names and paths

[deviantintegral]

At first glance, the Recurly PHP client appears to follow the PEAR standards for class names. However, it's only partially compliant:

• errors.php contains multiple classes.
• CamelCase'd classes like Recurly_InvoiceList should be in InvoiceList.php, not invoice_list.php.
• Case mismatches break basic attempts at class loading (Recurly_Account should be in Account.php).

For autoloading on projects that aren't using Composer to pull in the library, we have to fall back to a custom loader with the paths hardcoded.

I see two possibilities:

• Fix the existing codebase to comply with PEAR standards. It's old, but at least it's well supported and understood.
• Namespace the module, and refactor all classes to be PSR-0 or PSR-4 compliant.

[drewish]

Splitting out errors into separate files sounds fine.

I'm open to renaming files since our docs suggest require_once('lib/recurly.php'); and that should handling loading the other files.

I'd love to add namespacing but I don't see an easy way to add it and not break backwards compatibility with existing installations.

[vishalmelmatti]

• Recurly client should follow psr-4 standard.

[drewish]

@vishalmelmatti it would be great, but as noted would not be backwards compatible.

[aaron-junot]

As mentioned in #215 (comment), for backwards compatibility purposes, we're going to wait until version 3.x.x of the library to ensure compliance with a standard such as PSR.