Stricter `check_params` protocol for DA module would simplify debugging

[kachayev]

Describe the bug

ot.utils.check_params is used rather heavily throughout ot.da functions. The function itself checks for None(s) in the input and returns False if at least one was spotted. Now, there are 2 patters of how check_params is used in the code that are somewhat hard to debug when argument passed is, in fact, "invalid":

1. fit function works when check_params returns True, otherwise just returns self (example). As there's no exceptions thrown, the downstream code safely assumes that fitting is done.
2. transform returns the result of the transformation only in case check_params returns True, otherwise returns None (example).

In both cases, it's rather hard to find the cause as the issue is only reported using print statements.

Expected behavior

Suggestion here is rather simple: to follow stricter convention, for example similar to check_array in sklearn. Throwing ValueError in case invalid argument is provided seems to be safer option. What do you think? Happy to make a PR with the changes.

[rflamary]

Make sens, we should also probably move check_param in ot.da and change its name that is too generic.