Add Union Operator; Update AST

[KabirSamsi]

Background

#55 discusses a need for a modified AST that distinguishes between set-to-stream and stream-to-stream policies, and furthermore distinguishes between sets and streams. Within that, we discuss the need for a Union operator, which effectively 'merges several classes into one'. This is critical in the construction of Set-to-Stream transformers, to allow such polices to arbitrate independent of queue distinctions.

Overview

My work on the type system in #63 allowed us to realize that we could turn typechecking into essentially an abstraction, and have our set and stream types inferred at parsing-time itself – that is to say, with a tweak to the AST and extending it to the parser as well. That's the first part part of the PR, which entails adding in the Union constructor to the AST, and partitioning it into the set and stream types.

Caveat And Explanation

@polybeandip and I discussed how far we thought this change should extend. On one hand, modifying Ast.t contractually requires us to modify Policy.t. An alternative, though, is to simply establish a correspondence Ast.t -> Policy.t. For simplicity and to preserve the work done in control, we have kept Policy.t in its original form, and adapted that correspondence.

In turn, this required modifying almost all of our programs such that they would be syntactically correct w.rt. the new AST structure and parsing mechanisms. In addition, a few extra 'reversions' to allow for parsed programs to be correctly evaluated in control.

[anshumanmohan]

Thanks for tackling this; I see it ended up having a largish footprint! I have comment here about how fifo and union relate to other stream-to-stream policies (the example I have commented on involves strict).

[polybeandip]

LGTM! I left a few minor comments down below, but nothing too pressing.

The more I look at code now though, the more I feel like the stuff we do in policy.ml is super hacky lol. I know you made of_program convert from the new AST to the old one at my suggestion, but perhaps your original idea of changing Policy.t was the way to go. Maybe in a future PR, we can get rid of the simulator and that way making that change won't be as painful

[KabirSamsi]

@polybeandip Can you approve?