Breaking the entry wall into Sole

Hi guys,

In the figure below, we (Guido, @Perro2110, and I) propose a new structure for organizing Sole packages.

The rationale behind this issue is that, as of now, getting your hands dirty with Sole is not always friendly!
The last JuliaCon Paris 2025 has been enlightening in this sense: the current structure (see #22) might be clear at a glance for us, but the evidence is that it is not.

Ideally, one should be up and ready to play in a few minutes, but what I feel like (and I think I also speak on behalf of @alberto-paparella, @Perro2110, and @PasoStudio73) is that our use cases are simply fragmented.

Among all the solutions for reducing fragmentation and coupling, we decided to inject special "header packages" in the structure, whose purpose is to define abstract types, traits, and unifying interfaces for all their children packages, also re-exporting one or all of them *depending on your necessity*. Note that we are not defining submodules but, rather, simply regrouping distinct, thinner packages.

Ideally, each package that is not a "header package" should provide a few functionalities and should be simple to use, with short and friendly documentation, while header packages provide the essential knowledge you need to solve your problem (or implement your own solution), also naturally providing you with all the tools for tackling your use case.

So, here you are the new schema (written in Mermaid). I did not manage to put a legend, but I'll comment on the various colors below.

Starting at the top, we have `SoleGUI` (the name is still unofficial), which fully builds on `SoleXplorer`, and the latter, which *weakly depends* on all the other packages. We depict this weak dependency with a dotted arrow, meaning that a package could depend on all its neighbors in the schema, or just a subset of them, depending on the use case.

`SolePostHoc`, in green, will lose weight, keeping only the essential and delegating atomic functionalities to distinct packages. The packages I am referring to, generally called *post processing methods*, do not exist as of now and, hence, are colored in dark yellow.

`SoleLearners` is the header package of the various learning methods we provide and, since it does not exist, is colored in dark yellow. Note that the specific learners are no longer prefixed by "Modal", but "Sole".

Since the specific post-processing methods of `SolePostHoc` might strongly depend on specific learning methods... this is a subtle dependency, argh! We must be careful with these things, but the idea is that we can depend on a specific header and leverage the latter to only include the dependency we are interested in our Project.toml, probably via macros.

The same reasoning applied between some specific `SolePostHoc` to `SoleReasoners`, and from specific `SoleLearners` children packages to `SoleReasoners`.

Speaking of `SoleReasoners`, it is not colored in yellow, but purple, since it already exists as a solid package. If we want to let it become a header package, then all its functionalities will have to be split into multiple packages (the latter are colored in yellow since they do not exist right now, but they are light yellow, since we believe that splitting the code will not require more than a few hours: but hte last word goes to albi).

A similar reasoning as above applies to `SoleFeatures`.

Finally, the core remains untouched, with `SoleLogics`, `SoleModels`, and `SoleData` (I hope we will get rid of `SoleBase` and `MultiData` as soon as possible).

No concrete files or tests are specified. Start by reading package dependency declarations (e.g., Project.toml) for the listed packages: SoleXplorer, SolePostHoc, SoleReasoners, SoleFeatures, SoleLogics, SoleModels, and SoleData to see current coupling. Then compare that structure to the proposed header/leaf package design in the issue and image. Done means a concrete migration plan (with explicit package boundaries and re-export strategy) aligned with maintainers’ expectations.

由索引模型根据 Issue 内容生成。