feat(core): add service scoped database clients

[jrschumacher]

This PR introduces a significant change to how we perceive database clients within the platform. The original implementation has a concept of a single database client which services could use. As work was being executed, it became clear that the policy service was one (if not only) service which required a database client.

Recently, we learned that downstream projects that wrap OpenTDF required access to a database client, but this posed a couple concerns:

1. Downstream clients need the ability to add migrations and have those bound to the migration CLI tool as well as the auto-migration feature
2. We need to ensure a bad actor cannot poison a PEP and thus have easy access to mutate the policy outside an audited and authenticated flow
3. We need to ensure PEPs are interacting with services via contracts and not by direct database access, which could slow down development

Supported features

• create a new database client for each service / PEP
  • this sets us up to support limiting scope in the future by giving theoretical access to managing multiple DB user identities per instance of the platform
• scope the database client to a schema scoped to the service namespace
  • this will give us theoretical control over limiting the access of the database user
  • this might need to change to a database per service depending on the access controls needed
• add support for service based migrations
  • having all services use the same migrations directory is brittle since clients are scoped to schemas we can support multiple migration directories
  • additionally, when deploying a policy service apart from another PEP we don't want to automatically migrate a schema that won't be used
• migration commands now support service and/or --all
  • this enables developers to migrate up and down as they are exploring the process of supporting a new feature
  • this gives us the opportunity to enhance the tool to support migrations for services that are currently "enabled"

Unsupported features

• robust support for service auto-migration based on server registration
• rigorous performance testing
• DX review