Add missing semi-/sub-/-F/-Tap versions of flatMap to monad transformers

[catostrophe]

Monad transformers lack some semi-/sub-/-F/-Tap versions of flatMap that free a user from manual lifting or mapping.

I find the following items reasonable for implementation as to make structures and transformers more consistent:

• OptionT:
  • [x] add member methods flatTap, flatTapF, semiflatTap, subflatTap
• Either:
  • [x] add extensions flatTap, leftFlatTap to EitherOps syntax class
• EitherT:
  • [x] add member methods leftFlatMapF, leftSubflatMap
  • [x] add member methods flatTap, flatTapF, semiflatTap, subflatTap
  • [x] add member methods leftFlatTap, leftFlatTapF, leftSemiflatTap, leftSubflatTap
  • [x] add member methods biSemiflatTap
• Ior:
  • [x] add member methods leftFlatMap
  • [x] add member methods flatTap, leftFlatTap
• IorT:
  • [x] add member methods leftFlatMapF, leftSubflatMap
  • [x] add member methods flatTap, flatTapF, semiflatTap, subflatTap
  • [x] add member methods leftFlatTap, leftFlatTapF, leftSemiflatTap, leftSubflatTap
• IdT:
  • [x] add member methods flatTap, flatTapF
• WriterT:
  • [x] add member methods flatMapF, semiflatMap, subflatMap
  • [x] add member methods flatTap, flatTapF, semiflatTap, subflatTap
• Kleisli:
  • [x] add member methods flatTap, flatTapF
• IndexedStateT:
  • [x] add member methods flatTap, flatTapF
• IndexedReaderWriterStateT:
  • [x] add member methods flatTap, flatTapF

Open questions:

• [x] flatTap automatically comes from FlatMap syntax. For some transformers it has a special implementation (e.g. for EitherT), for others it is standard (e.g. for OptionT). Should we add it to the latter for symmetry and consistency? (Added)
• [ ] EitherT has biSemiflatMap. Do Either/EitherT/Ior/IorT need biFlatMap with all the semi-/sub-/-F/-Tap versions?

[catostrophe]

All changes are binary compatible. All done except for open questions. Tests to be written.

[i-am-the-slime]

So close...