Change MonadError from F[_, _] to F[_]

[ceedubs]

I was working with MonadError today and the F[_, _] approach made me use
quite a few type lambdas when I was working with types like Future/Task.
Since the error type is already encoded as another type parameter, as
far as I know we don't really lose anything by using a type constructor
with a single parameter for F.

It's quite possible that there's a reason for using F[_, _]. If anyone
knows of one, please speak up.

[non]

I don't have a strong opinion of this change. It seems reasonable to me.

If no one speaks up against it then I would say 👍

[ceedubs]

@adelbertc I think you added MonadError. Do you have any thoughts on this? @tpolecat I have heard you chat about error-y type classes like Catchable, MonadError, etc. Do you have thoughts?

[codecov-io]

Current coverage is 75.76%

Merging #553 into master will decrease coverage by -0.13% as of 3bdaf80

@@            master    #553   diff @@
======================================
  Files          156     156       
  Stmts         2112    2117     +5
  Branches        68      68       
  Methods          0       0       
======================================
+ Hit           1603    1604     +1
  Partial          0       0       
- Missed         509     513     +4

Review entire Coverage Diff as of 3bdaf80

Powered by Codecov. Updated on successful CI builds.

[adelbertc]

Hm, this is a lot nicer and no consequences that I can think of at the moment. 👍 from me, though perhaps we should wait to see if @tpolecat has any concerns before merging?

Also should probably do the same for the other ones, MonadState and MonadReader

[non]

@ceedubs assuming @tpolecat does sign-off on this, do you want to follow @adelbertc's suggestion and modify MonadState and MonadReader also?

[ceedubs]

@non @adelbertc sure that looks like it would work. I might not get to this for a couple of days, but I'll give it a go.

[ceedubs]

I updated MonadReader and MonadState.

@adelbertc you mentioned that you were becoming a big fan of these type classes. Do you have a code base using these that you could compile against this branch to see if there might be unfortunate implicit resolution/inference implications? Or are they using Scalaz and not Cats?

[non]

If @adelbertc signs off on these then 👍 from me too.

[adelbertc]

Looks good to me - the code I have that does use these are all living in Scalaz currently. That being said the tests seem to pick up the instances just fine, so 👍 :-)