feat: abstract PolicyManager and policies to allow extensible and sharable policies

[SeanJCasey]

This PR makes the PolicyManager more versatile and extensible, specifically in order to pave the way to handle various kinds of vault integration adapters. It follows a similar structure to the abstracted Vault().callOnIntegrations(), in that it simply takes a bytes _encodedArgs param, the encoding schema of which is particular to each policy. It also implements a hook system by which a policy specifies where (PolicyHook) and when (PolicyHookExecutionTime) it should be executed.

This PR also makes policies sharable between funds, so that the official policies are registered to the Registry, and are then simply enabled on the fund, with fund-specific config stored on the policy itself.

There are also significant changes to how risk management arguments are provided in callOnIntegration:

• lift checking if an asset is registered to callOnIntegration (from individual adapters)
• lift policy validation calls to callOnIntegration (from individual adapters)
• have each adapter provide a list of expected incoming assets for a transaction, which is callable from callOnIntegration
• calculate all incoming and outgoing assets in a callOnIntegration by comparing pre-/post-action balances, and use these values for risk management policies
• refactor policies to use incoming / outgoing assets and amounts, rather than specific things like 'makerAsset' and 'takerAsset'

[SeanJCasey]

In each policy, we currently don't have an external function that allows checking a rule against a specified fund with specified args. If we wanted to, we could include a passesRule() function that allows testing of the rules for a given fund with certain parameters, and then validateRule() (for a fund) would simply pass the msg.sender and args to passesRule(). It's not strictly necessary, so I didn't include it for now.