drop support for method-based API

[davidchambers]

Function-based API:

List.case({Nil: () => ..., Cons: (head, tail) => ...}, list);

List.case({Nil: () => ..., Cons: (head, tail) => ...})(list);

Method-based API:

list.case({Nil: () => ..., Cons: (head, tail) => ...});

I would like to drop the method-based API for several reasons:

• One way is better than two (for users primarily; implementation simplicity secondarily).

  $ python -c 'import this' | grep 'only one'
  There should be one-- and preferably only one --obvious way to do it.

• this is an implicit argument. Explicit is better than implicit.

  $ python -c 'import this' | grep 'implicit'
  Explicit is better than implicit.

• The function-based API supports partial application and thus works well with Ramda-style functional pipelines; the method-based API does not.

• Sanctuary favours functions (for the reasons listed above). It provides a fromMaybe function, for example, rather than a getOrElse method.

How do you feel about this proposal, @JAForbes? I realize I'm pulling the project further from your goal of maintaining backwards compatibility with union-type, but union-type embraces JavaScript's dynamic nature whereas Sanctuary projects do not. Optional arguments, ad hoc polymorphism, and this are used heavily in union-type, but are at odds with the Sanctuary philosophy.

[JAForbes]

I agree. Pending your decision on #6 I think dropping all instance methods is a great idea.
I think it might be worth considering the proposal I made in #6 as well about having a single case function that acts as a pattern matching operator. But I'm not wed to any particular implementation as long as I have a backwards compatible version living somewhere.