Implement sparks based scheduler

[rrnewton]

• Separate package from LVish with minimal depends
• Will only be an instance of ParFuture/ParMonad, not ParIVar
• Can be modeled on the monad-par version of same

This should be able to exercise some generic set of Par tests which can apply to both LVish and this new implementation.

[osa1]

We'll need some newtypes for this. Where should I define those?

• par-classes: Seems like a bad place because we may want to keep this small and simple. This change will introduce a monad-par dependency and an implementation. (currently we only define interfaces in this package, it doesn't have any implementations)
• par-transformers: Seems unrelated.
• par-collections: Seems unrelated.
• lvish: May be a good place since current scheduler is also defined there, but we don't need any lvish functionality and we may want to import other schedulers without importing the whole lvish?
• new package: Seems like the best option for me. We can call it par-schedulers.

[osa1]

As previously discussed, we need some refactoring in ParIVar, ParFuture etc. class hierarchy, but the branch for that is causing a lot of trouble now(par-classes-refactor).

So I started gradually merging that branch and I'm hoping to find the patch that's causing breakages on the way.

[rrnewton]

Could you link to a failing CI test log for the trouble? Failing sort tests right?

[osa1]

I'm afraid we don't have any CI logs for that, because CI was failing with build problems. I was running tests on my laptop, and approximately 1 out of 10 runs was succeeding, others were failing with "array not sorted" errors and they were sometimes getting stuck.

I tried to implement a MVar-based ParFuture implementation for LVish scheduler(c88abdf), and when I used that in par-mergesort it started to fail with "Blocked indefinitely on MVar operation" errors.

[rrnewton]

Ok, I'll try to code review (c88abdf) soonish.

[rrnewton]

Put the feedback in-line in the commit.