Prefer to check the constraints in the manager level

ForeignKey is used widely in the SQL backend, and ForeignKey is normally coupled with ondelete parameter, typical values of ondelete include "CASCADE", "DELETE" and "RESTRICT".

If no value is given for this parameter, "RESTRICT" is default value which means the parent entry can not be deleted before the child entries are removed, or else the error "ERROR 1451" will be thrown when trying to remove the parent entry first.

*** In order to delete parent entity successfully, Keystone have done something in the driver layer, typically, remove the child at first and then remove the parent. It shows "RESTRICT" in table schema becomes useless in this case, and as Keystone has different backends besides MySQL, we should rely less on the DB itself to give us some error to learn something from the DB. so we can migrate the FK definition from "RESTRICT" to "CASCADE", this will also help to reduce database round trips.

The entities which have such behavior includes,
endpoint/service: Delete service will remove the referenced entries in endpoint at first (This is the existent logic, same below.)
request_token/consumer: Delete consumer will remove the referenced entries in request_token at first.
access_token/consumer:Delete consumer will remove the referenced entries in access_token at first.
user_group_membership/user: Delete user will remove the referenced entries in user_group_membership at first.
user_group_membership/group: Delete group will remove the referenced entries in user_group_membership at first.
project/domain: Delete domain will remove the referenced entries in project at first.
project/project: Delete project will remove the referenced entries in project at first.

The main changes here is the DB migration.

*** For those entities which not allow to remove the parent when it has children, it makes sense to define the FK with "RESTRICT" parameters, so the behavior will be consistent between Keystone manager and DB itself.

The entities which have such behavior includes,
endpoint/region: Delete region will raise "RegionDeletionError" when endpoint has a reference with region.

There is no changes needed here.

*** As to those entities which remove the parent without removing the children at first, this will prone to exceptions if no "CASCADE" is used, Keystone need to remove the children before removing the parent as well and also add "CASCADE" parameter to FK.

The entities which have such behavior includes,
federation_protocol/identity_provider: Need change the code in the driver layer to remove referenced entries in federation_protocol before removing identity_provider.
project_endpoint_group/endpoint_group: Need change the code in the driver layer to remove the referenced entries in project_endpoint_group before removing the endpoint_group, current relationship will lead to failure when deleting endpoint_group.

The main changes here is DB migration and some logic in the driver layer to hande with the reference.

Pending to be discussed, Should we move some logic from the driver layer to manager layer? both for existent and what is expected to be added in the future, saying, if we want to delete the domain we'd better to check the reference in the manager layer and delete the reference at first instead of doing it in each driver?