The ApplicationForm and UserApplicationForm have been refactored

into the following:

ApplicationCreationForm, for creating applications in the admin

  site and through the API;
AppplicationChangeForm, for updating applications in the admin site

  and through the API;
UserApplicationCreationForm, for users to create applications; and
UserApplicationChangeForm, for users to edit applications.

These forms are now more locked down: none of them accept client_id or

client_secret fields. Instead, the *CreationForms will generate

those when creating a new Application. The *ChangeForms will show the

client_id and client_secret fields to users, but any changes made to

them will be ignored.
The above forms now all reject enabling an application that has been

disabled for security reasons (i.e., the original owning user was removed

from the local site the Application is associated with).
The API now is more strict about enabling Applications that have been

disabled for security. Previously, passing enabled=1 into the API

would re-enable a disabled Application and regenerate its client secret.

This behaviour has been updated to explicitly require the

regenerate_client_secret field to be set set truthy. Otherwise an

error will be returned (the same error that is returned when attempting

to enable an Application disabled by security through the above forms).

Ran unit tests.