WIP: factor out Scalaz dependency

[rossabaker]

This doesn't compile yet, but is far enough along to illuminate #321.

Basic idea:

• shims provides necessary stubs of scalaz.concurrent._ and trampoline. This will go away.
• core depends only on scodec.
• scalaz contains the nice integration with scalaz7. Should live in its own repo when it grows up. Siblings might include scalaz8, cats, structures, etc.

What's broken:

• A few things exploit Task and ByteVector instances of type classes that were exiled. These require specialization.
  • Notably, a few things in core run Process[Task, ?], but there is no specialized run.
• Without compiling core, I don't know what dragons await in scalaz.

What stinks:

• Specializations of things we can get for free in multiple places.
• Ours would be at least the third copy of scalaz.Free.Trampoline / cats.free.Trampoline.
• The return of scala.Either, including it being prominent in the shimmed Task.
  • To maintain merge sanity for a bit, this is still aliased to the Scalaz names, with some syntactic sugar.
• Import tax due to decoupling instances from companion objects.
• All the code in the scalaz module would be copied, pasted, and gently tweaked for cats, scalaz8, etc.

Discuss.

[pchlupacek]

@rossabaker excellent

on the Task, in fact I was thinking to perhaps implement it w/o Future, and that remove / from the task alltogether. I didn't see anyone actually using Future directly, so I think we don't need the future at all.

Part of to take this approach and motivation for me was to make Task very solid and more deterministic in case of interruption of asynchronous callbacks.

I think we may just need temporarily to shim task with sort of / syntax, so we won't need to refactor all the code. And that for me can live in scalaz._ module.

We also need to think if we really need to have scala.Either as primary primitive in Task (for attempt) perhaps, we can use Cause for this and that way we may not need Either alltogether. Then, it will nicely play with Halt(cause) we use in Process.

I was thinking on something like

sealed trait Task[+A]

.... all current algebra of Future as is (perhaps we may need to touch async algebra)

sealed trait TaskResult[+A] extends Task[A] 

case class Done[A](a:A) extends TaskResult[A]
case class Failed(c:Cause) extends TaskResult[Nothing]

 def attempt: Task[TaskResult[A]]
 def attemptRun : TaskResult[A] 
 def run: A

As for the Trampoline, this just prevents stack safety, I would be curious if we really need Trampoline separate from task, or we may reuse task instead of trampoline (Look on number of Try() we use there as the Trampoline does not have such concept)

@pchiusano your view on this? Any ideas?

Perhaps we can redefine Future and use it internally, and put Task to scalaz module only for compilation compatibility, but internally use only Future (extended with Cause etc)?

I don't have any strong opinions on any of propositions above, but would like to bring them on table before we just do copy and paste. :-)

I know @pchiusano you and @runarorama were discussing new IO, can we perhaps use some of your work/ideas here?

[rossabaker]

@aloiscochard is also doing some interesting IO work on the scalaz 8 branch.

[rossabaker]

I'm working on a cleaner version of this based on more recent discussion. This PR is obsolete.