Add main classes/functions to parent namespaces

[tyarkoni]

It's a bit tedious to have to, e.g., from nimare.meta.ale import ALE. it forces users to have a grasp of the internal module structure, and there's probably no reason for it. I'd suggest including key objects located two levels below root in their parent namespaces. I.e., from nimare.meta import MKDADensity; from nimare.decode import gclda_encode, etc.

[tsalo]

I've vacillated on this in the past, and I recall two issues (one certain and one possible). The certain issue is that having access to the same object at multiple levels breaks interlinking in the documentation (#220). My solution was to restrict the classes to their immediate namespaces, but there may be a better solution that I just couldn't find at the time.

The possible issue is circular importing; such as when one class/function in a file requires access to another class/function in another file, but something in that file requires access to something in the first file. I am not 100% sure this will happen if we restructure the namespaces, but I think it's especially likely once we start moving all of the base classes to their associated modules.

EDIT: I'm not saying that clean links on the RTD site are more important than an interpretable package structure. I just want to avoid that particular bug if at all possible. The links weirdly resolved to parent classes, and that would just confuse folks.

[tyarkoni]

Not sure about the doc issue, though we could look at how other packages with modules nested several levels deep do it. IIRC Sphinx has a directive you can use to exclude objects from showing up.

Re: circular imports, I don't think they'll be an issue. It may take a little bit of restructuring, but I think we can make it work, and worst case, we'll just put any problematic imports in local scope. I think ease of use should take precedence here.

[tyarkoni]

This is partly done in #393 (for stuff under meta).