Refactor match compiling to accept user-defined logic.

[catalinadurbala]

What I'd like to achieve here is having the match output compilation be customizable - I don't necessarily need the rest of CompileMatches, but I thought it might be simpler to reason about it as a whole. Please let me know if you'd prefer a different approach.

[TristonianJones]

Hi Catalina, I'm struggling to understand the usage pattern you're looking to enable. Could you help me understand the use case better? The API change is substantial, so I'd prefer not to make the change as-is without having a really compelling usage scenario. Perhaps there are simpler alternatives to consider?

[catalinadurbala]

We would like to be able to compile an AST that outputs structured explanatory metadata instead of the actual output for a given policy. What we do now is compiling a policy once for the output, mutating the policy to swap the metadata (explanation) for its output, and then compiling this mutated policy again. While hacky, this works for the single string explanation field that we were using so far. However we now need more structure in our explanations (i.e. a proto that we parse from multiple match subtags) and we'd also like to keep line and column information for all of the components.

Ideally we would be able to use branch annotations and only do one policy compilation that yields both the actual output and explanations for it. As second best, we would like to leave the policy as it is and instead be able to customize the output compilation - #974 is related, but we've realised that we would benefit from more structure for the explanations and therefore the current Explanation field would not suffice anyway.

Please let me know if there's a different approach that you prefer that would help us achieve this. TIA!

[catalinadurbala]

Closing this in favour of #1246.