Port Over Simulator and Compiler from `pifo-tree-artifact`

[polybeandip]

This PR makes the following changes

• fill in ocamlformat
• remove bin/
• alter WFQ to weights to be float instead of int (necessary to implement WFQ_Ternary in schedulers-in-ocaml)
• alter file structure to have two libraries, Frontend and Simulate
• remove NWC policies and EDF, SJN, and SRTF in policy.ml; constructing controls for them is for later
• port over simulator and compiler from schedulers-in-ocaml
• implement Control.of_policy (most of the work for this PR)
• setup T2T compilation tests in tests/compilation: i.e. check the .csvs match
• add two work conserving programs: ternary strict and wfq

To generate graphs via our simulator, cd into dsl/ and run

dune clean; dune build; dune test; python ../graphs/plot.py

This populates graphs/

[polybeandip]

Yahoo, all graphs match now!

[polybeandip]

I'm sorry for the size of the diff.

While the additions are inflated by copying code from schedulers-in-ocaml, this still should have been multiple PRs; I got a bit carried away with making changes.

[anshumanmohan]

Super duper! Before I do a real review, a quick question: in copying over schedulers-in-ocaml are you taking us to a monorepo model? So both the pieces of code live here in this repo and we eventually delete the other repo? An alternate to deletion is to use a git submodule to house what is currently schedulers-in-ocaml.

The broad alternate to a monorepo is that we actually keep the repos separate, and that we request the user to download the two as sibling directories. Then we write some interstitial code that reifies the connection between the two repos. By and large I think @sampsyo and the lab are a little iffy about this second style

[polybeandip]

I copied schedulers-in-ocaml code because it seemed like a quick way to connect our DSL to a T2T compiler and simulator: it wasn't a very well thought out decision 😬

are you taking us to a monorepo model?

Long term, I'm conflicted on what the best choice is.

If we ultimately decide to use this T2T compiler for converting between topologies (i.e. following the blue path in #38), then moving to a monorepo model makes sense. Maybe just the simulator can be separated out? However, if we choose not to use this compiler, we'd likely rewrite it (either from and to DSL programs or between Calyx eDSL programs). In that case, maintaining two separate repositories or a git submodule seems best, as our simulator and OCaml compiler would be auxiliary utilities rather than central to our workflow.

[anshumanmohan]

Agreed; not clear what would be best. But then again it doesn't seem like it would be too too hard to reverse any of these decisions as long as we promise to avoid any large changes to theschedulers-in-ocaml code, either here or there. With that promise, let's just have you go ahead. I don't want to bikeshed this. Review coming up!

[sampsyo]

"Let's just do it and worry about the right final decision later" seems about right to me!