Merge all OT mapping methods in one class

[rflamary]

Should we merge OT mapping methods?

it seems like the use of entropic regularization or group lasso could be added easily as a parameter to the same class. We should probably keep LinearOTMapping separate because it is very different in term of mapping but the OTMapping, EntropicOTmapping and Grouplasso could be merged in one class in my opinion and it would make SKADA less OT biased ;).

Another question is if we should move them in _ot.py . on this one I'm a little more circumspect since those are mapping method and they probably belong with CORAL...

[kachayev]

I agree it would be more convenient to have all methods that rely on POT in a separate module. In such a way, we can make POT into an optional dependency.

Regarding merging OT mappings, are there separate papers that introduced them? I guess if we stick to 'one paper = one method' razor, we should keep wrappers. If that's not the case, we can surely squash all of them together.

[rflamary]

About papers : some papers propose very different models (the target shift and other implemented bu @antoinecollas for instance, or classifier/regerssor for JDOT) so one method per paper is probably not a good idea as a general rule.

But for OT methods, they have all been more or less introduced as variants in the OTML PAMI paper so it makes a lot of sens to factorize.

About POT as optional dependency this is a question because it would amputate a number of methods with a default install. I'm of course totally biased ;) . We have also several OT methds not based o mapping to implement so having both OT mapping and non maping together might not be best. maybe we can make _mapping as a folder and have diffeent files to separate OT and others?