Add foldRightDefer to Foldable

[denisrosca]

This PR adds foldRightDefer to Foldable[F] with the following signature:

def foldRightDefer[G[_]: Defer, A, B](fa: F[A], gb: G[B])(fn: (A, G[B]) => G[B]): G[B]

A new law to check the foldRight <-> foldRightDefer equivalence where type G[A] = Eval[A] was also added to the test suite .

To avoid binary incompatibilities, I added the function as a syntax enrichment for Foldable[F] and F[A] given a Foldable[F].

Closes #2678

[kailuowang]

Thanks very much!
It's a bit confusing, though, to have a law testing a method added through extension.
I see two options

1. add the method to the type class directly and wait for the branch post 2.0 release
2. comment out the law and test with a note that it's pending the method being moved into the type class post cats 2.0

I lean towards option 1 unless having this method is urgent to you.

[codecov-io]

Codecov Report

Merging #2772 into master will decrease coverage by 0.02%.
The diff coverage is 75%.

@@            Coverage Diff             @@
##           master    #2772      +/-   ##
==========================================
- Coverage    93.3%   93.28%   -0.03%     
==========================================
  Files         376      376              
  Lines        7316     7323       +7     
  Branches      187      199      +12     
==========================================
+ Hits         6826     6831       +5     
- Misses        490      492       +2

Flag	Coverage Δ
#scala_version_212	93.61% <75%> (-0.03%)	⬇️
#scala_version_213	90.91% <75%> (-0.04%)	⬇️

Impacted Files	Coverage Δ
...ain/scala/cats/laws/discipline/FoldableTests.scala	100% <100%> (ø)	⬆️
laws/src/main/scala/cats/laws/FoldableLaws.scala	100% <100%> (ø)	⬆️
core/src/main/scala/cats/Foldable.scala	98.16% <50%> (-1.84%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f1ead7d...1cd2714. Read the comment docs.

[denisrosca]

I don't really mind either way. I just thought you would prefer something that could be merged immediately.

I'll move the method to the typeclass.

[kailuowang]

Thanks very much!

[johnynek]

I would imagine inlining Eval.defer will give a slight performance improvement since the jit can at best do this inlining later.

[denisrosca]

@johnynek not sure I understand. Are you saying you would prefer the previous implementation explicitly calling Eval.defer?

[travisbrown]

@denisrosca Do you mind merging master and changing the iterateRight implementation back to use Eval.defer directly as @johnynek suggested? Otherwise this looks good to me and it'd be nice to get it into 2.1.0. Thanks!

[denisrosca]

@travisbrown Don't mind. Hopefully I'll get to it this week.

[travisbrown]

@denisrosca Would you mind if I do it now and push to this PR branch? We're aiming to publish 2.1.0-RC1 on Friday and it'd be great to get this in.

[denisrosca]

I don't mind if you prefer to do it now. Thanks.

[travisbrown]

@denisrosca Thanks, done! I'm happy to see this merged when green. @johnynek?

[johnynek]

Note, the addition of Iterable to Foldable in #2380 would allow us to use the iterateRightDefer method rather than the foldLeft implementation which I think will be more efficient (and I think allow short circuiting).

[johnynek]

Thanks for adding this BTW!