Synchronicity

These changes allow for the existence of a backend runner which acquires a mutex using withMVar within which all rendering occurs, so that rendering (including the computation of the virtual DOM and the running of potatoes) is effectively a synchronous, non-parallelizable operation. This is not necessary for the correctness of pure Shpadoinkle programs, but it is helpful for embedding JS libraries which do not function properly in the presence of multiple concurrent rendering pipelines.

The key changes are in the shpadoinkle function. Instead of running the backend's natural transformation to JSM multiple times per setup and multiple times per go, I run it once per setup and once per go, and by getting rid of nested calls to the natural transformation, I allow for a mutex to be acquired. This changes the type of setup, which in turn requires a proxy to be fed into the shpadoinkle function in order to assist with typeclass instance resolution.