`MLJBase.scitype` conflict with `ScientificTypes.scitype`

Currently MLJBase and ScientificTypes both export scitype, which creates a name clash. This has not appeared to have caused many problems because MLJBase, which has ScientificTypes as a dependency, re-exports all the other names that ScientificTypes exports, so there is generally no need for the MLJBase user (or MLJ user) to also do using ScientificTypes. But this state of affairs is confusing, and I hit my head against it recently. The issue is that MLJBase.scitype is not just a re-export of ScientificTypes.scitype (even though the first does in fact call the latter). This has to do with the "light/full interface" switch we created to ensure MLJModelInterface could be ultra-light weight, but still refer to names in packages that aren't dependencies ... a long story I'll not go into here, except to say this "hack" has another drawback: the global variable which flags whether we are using the "light" interface (MLJBase is not loaded) or "full" interface (MLJBase is loaded) kills the benefit of adding a precompilation load to MLJ (there was an issue about this, but I cannot find it just now).

What to do about this? Probably any solution is going to create significant breakages, so probably we live with this until such time as we eliminate the "hack" referred to above, which is probably rendered unnecessary with the advent of weak dependencies and conditional code loading. But I wanted to flag this issue.

Start by tracing the scitype exports in MLJBase and ScientificTypes and the light/full interface in MLJModelInterface. Review how weak dependencies and conditional code loading could affect the existing interface and precompilation behavior. Done means an agreed resolution with its compatibility and breakage implications documented.