Lack of consistency in dataset class parameters.

When we initialize a class, we can pass the number of subjects in some objects and not in others. We can pass a list of sessions or a number of sessions.

The same goes for other parameters, as sometimes we have return_train, and other times, we also have datasets that have double options, such as imagined and executed. In addition, some datasets receive args and kwargs without much explanation.

What I propose is to change the initialization of all classes and establish some protocol to determine how to call these classes.

The draft of my proposal is:

1. Incorporate the subject_list in the dataset parameters, and stop making this assignment in the object after the dataset is defined. This is clearer, makes more sense, and avoids the technical adjustments we make in the documentation.
2. Special sessions should have the session prefix, for example: session_imagined; session_resting_stage
3. Other sessions should receive a list of the sessions that will be loaded.
4. No dataset should have args or kwargs, since the exposure of the parameters must be complete.
5. No parameters should be hardcoded inside the class: doi, url, code should be defined as constants, and events should be exposed.

I am happy to discuss this in the next moabb meet :)

The issue names no files, tests, or entry points, so begin by inventorying the dataset classes and their current initialization parameters. Review the proposed protocol and define the scope with maintainers; done means the affected classes consistently expose explicit parameters without args or kwargs and follow the agreed session and metadata conventions.