Move deletion business logic out of controllers

Based upon the feedback on the credential_api deletion changes,
the deletion code should be moved down to the managers from the
controllers. This means the business logic to delete / modify
associated resources based upon a given action no longer resides
in the controller. The changes include (but are not limited to)
mass token deletion (delete_tokens_for_(user|trust|project|domain),
domain content deletion, credential deletion, etc.

This change also moves around the use of @dependency decorator
to ensure the *_api managers are added to the correct objects.

The token_api has been expanded to handle the token revocations
for users, projects, and domains directly (public methods). This
allows the managers to handle deletions rather than the
logic residing in the controllers; it was previously not clean
to issue a `delete_tokens_for_user` outside of the controller.

A few minor test changes and additions were needed to handle the
moving of business logic. Notably, the keystoneclient tests
(test_keystoneclient) CompatTestCase needs to setup SQL for the
credential_api to be able to perform delete logic.

bp: assignment-controller-first-class
Change-Id: I721e49258c10830b3c44f301e8c9e5f954262388
Break dependency of base V3Controller on V2Controller

With the cleanup that has occured, it is now possible to make the
V3Controller to stand on its own with out needing to inherit from
the V2Controller. To accomodate this change, `_require_attribute`
has been moved from V2Controller to keystone.common.wsgi.Application.

Change-Id: Id5cd5384a100a5d3de6beac2ba445854a2e8e6fd
bp: assignment-controller-first-class
Merge "Move deletion business logic out of controllers"
Merge "Break dependency of base V3Controller on V2Controller"