People Controller - No User Error Handling Change

In the case where an unauthenticated user visits the people controller and does not provide any arguments via the URL thereto, the people controller will now raise a 400 Bad Request rather than a 403 Forbidden.

This is a more logical response, due to the fact the permissions system is sufficiently general to allow unauthenticated users to view people.  Therefore this situation is not necessarily the request being forbidden (although currently any attempt by an unauthenticated user to view any user will be forbidden later in processing), but is rather the request being malformed (it's a request to view the currently logged in user, but there isn't one).
DataSource::CreateOrganization

Added a CreateOrganization method to the GFOABC\DataSource interface.  This mirrors the functionality of the CreatePerson method.

Implemented this method in the GFOABC\MySQL\DataSource class.
People Controller Fix

Fixed a type in the \GFOABC\Controllers\People class which was passing the wrong \GFOABC\Person through to the \GFOABC\TemplateFactory when creating the person.phtml template.
Revert "People Controller - No User Error Handling Change"

This reverts commit f2c5f2b572650c61ffc45cd20d5581c3cb279eab.

After reviewing this change, I had (for some reason) believed 403 Forbidden was being raised, when in reality 401 Unauthorized was being raised.  This makes more sense than 400 Bad Request because:

-	The request may not actually be bad, insofar that the person-in-question may actually be a user who hasn't authenticated yet.  Since authentication may ameliorate the issue, 403 Forbidden is not an appropriate response.
-	\GFOABC\AuthenticateController will pick up 401 and 403 errors and redirect to a login, giving the user a chance to login rather than a somewhat-cryptic error page
Organization View/Edit Permissions

Added organization-related methods to the \GFOABC\Permissions interface:

-	ViewOrganization: Determines whether a user can view an organization
-	EditOrganization: Determines whether a user can modify an organization
-	ViewOrganizationPDPoints: Determines whether a user can view an organization's PD points balance
Schema - payments Fix

The `subtotal` column of the `payments` table was incorrectly NOT NULL rather than DEFAULT NULL.
Schema - Remove `pd_points` Table

Removed the `pd_points` scratch table from the schema.

It was previously used by the implementation to cache PD points calculations, but that idea has long since been dropped.
Organizations Controller

Added the \GFOABC\Controllers\Organizations class, which fills the same purpose for organizations as \GFOABC\Controllers\People does for people.

Also updated the organization.phtml template to support changes since the old, pre-refactor controller.
TemplateFactoryImpl Update (Permissions, Current User)

When a TemplateFactoryImpl object creates a template, it now also passes through a \GFOABC\Permissions object.

Also, the TemplateFactoryImpl object now passes the currently logged in user through as "user" rather than "person", which better reflects its meaning.
\GFOABC\DataSource::GetPaymentByID

Added the GetPaymentByID method to the \GFOABC\DataSource interface, and \GFOABC\MySQL\DataSource implementation thereof.

This method mirrors the functionality of \GFOABC\DataSource::GetOrganizationByID and \GFOABC\DataSource::GetPersonByID, but for \GFOABC\Payment objects.