Update management frontend #464

The "management" frontend is used to manage optional Rego policies for schemes. The original intent was for this to host a richer general management API for the rest of services (hence the name), but that never materialized, and is probably not needed at this point.

This frontend is problematic for a number of reasons:

• This is the only frontend that doesn't talk to the VTS and instead interacts with the stores directly. This is not much of an issue in our current deployments, but if we want to do truly decentralized deployments in the future (and this wa original motivation behind VTS/frontend split), this might become a problem.
• After the corim-store migration, this is the only use of the kvstore component. This is not necessarily an issue, but it does complicate configuration and deployment, since two completely different stores needs to be set up and configured. Ideally, we'd want a single Store "layer" for the VTS that is configured uniformly, and the same underlying DBMS is used for both endorsements and policies. Also, kvstore is intentionally very generic as it was used for trust anchors and refrence values as well in the past. This makes it pretty limited (both keys and values are essentially treated as opaque strings). Given that generality is no longer an issue, we might want to have a more structured schema for the policy store, which would make it easier to query/manage contained policies.
• The front end is not very well unit-tested at the moment. We should set up mocks-based unit test infrastructure, similar to what we have for the other frontends.
• Lastly, we should probably rename this to make it clearer this is a policy related endpoint.