Use sedwards-lab/ssm library directly

[j-hui]

@sedwards-lab very recently refactored the upstream runtime library at https://github.com/sedwards-lab/ssm . It simplifies my own refactor (on that repo's sched branch), which I had ported over earlier (in #30). The library is integrated into this repo as a git subtree (rather than the more common git submodule approach). This technique directly splices sedwards-lab/ssm's git history into this repo's history, so there isn't any need to do git submodule init or anything of the sort. This should discourage invasive changes to the runtime library from here, but should the need to make changes arise, it's also possible to push only the commits from the runtime subdirectory back upstream.

There's still a load of work to be done here, but I'm opening this PR now as a draft to document planned changes to existing components of this project. In particular:

• [x] All SSM library-relevant symbols are now updated to have ssm_ as a prefix. A lot of other symbols are renamed too, following Stephen's changes.
• [x] The edsl compiler is no longer responsible for synthesizing the main function (fixing #33); instead, the main function is defined by the platform, which invokes whatever is pointed to by ssm_entry_point to kick off the SSM execution.
• [x] The semantics and structure of the event trace is redesigned and simplified (addressing #24 and making progress on #17 ), so as to be less invasive with respect to the runtime library (which should be tested separately anyway). That is, the event logging is lifted out of the runtime library and the type implementation (the update function). Instead, that logging is delegated to the platform main loop driver and the generated code.

At this time of writing, I'm still working on the event trace semantics, but I'm planning on logging the following events:

• The names of and arguments to all procedures upon forking
• The length of the event queue between ticks
• The time of the next event prior to calling tick (i.e., what the next now will be)
• ~The value of all local variables upon entering and leaving the step function (how I'll handle uninitialized variables is not yet clear)~ Removing this for now because this saves me a little time fussing with uninitialized values and string formatting in C. That being said, we can easily distinguish by initialized vs uninitialized values by looking at the last_updated timestamp. So it shouldn't be too hard, just more code.

The former shall be logged in the generated code, while the latter two will be logged by the main loop driver of the trace platform.

At each step, the generated will increment a microtick that will be used bound non-terminating generated code.

Each event trace will also terminate with one of the following conditions (EDIT: see ssm/SSM/Interpret/Trace.hs for details):

• terminated gracefully
• microtick exhausted (did not terminate)
• act queue full
• event queue full
• depth exhausted
• invalid after (e.g., earlier than now)

There may be a need for more event traces or terminal conditions, which I will discover as I proceed.

[j-hui]

Currently, this branch is generating compiling code when the entry point takes no arguments. I still need to adjust the compilation interface to check for and enforce this, and modify the test suite to wrap all generated functions with a parameter-less main functin. In doing so, I'll also clean out some test cases which don't actually document what they're testing, addressing #41 .

[j-hui]

@Rewbert not yet ready for merging, but maybe good to start reviewing now. I've highlighted some important changes with comments.

stack test isn't quite working yet, and most of the regression tests are broken. This is because we now have a new requirement that the entry point of compiled programs abide by a particular type signature which almost none of the regression tests abide by. I will fix these soon.

We've already discussed offline (i.e., Slack), but this PR in its current state drastically weakens the expressiveness of the event trace. This shouldn't be too hard to add back in, but it'll be a little fussy. @sedwards-lab and I discussed useful things to add to the event trace and concluded that while more fine-grained event logging may help us find other bugs, the compiler is in a more stable point that this is not a priority, compared to getting the full build pipeline (e.g., getting I/O working) working.

[j-hui]

@Rewbert all tests are passing again, this is ready for full review

[Rewbert]

I'll take a closer look at this pull request next week, when I am back in civilization :)

[j-hui]

Merging this into master now because this PR is becoming a behemoth. Thanks for all the great work everyone!