Reorganize Hy internal imports

[scauligi]

As noted in #2131, Hy ends up loading most of its internal modules just from the initial import of the top-level module.
Turns out it's not entirely trivial to fix this, since we have complicated dependency chains such as hy.importer._inject_builtins() needing hy.macros.load_macros(), but hy.macros imports hy.compiler (which itself imports macroexpand back from hy.macros...)

The whole thing is fragile enough that (naive) initial attempts just result in a bunch of ImportError: cannot import name '...' from partially initialized module '...' (most likely due to a circular import).

I think the proper solution for this is going to be a (potentially invasive?) reorganization so that dependencies are much clearer/saner and so that we actually get the benefit of just-in-time submodule loading.

[scauligi]

orrrrrrr my sleep-addled brain forgot to remove the early call to _inject_builtins in __init__.py.

That being said, (at least as it currently stands) anything that calls _inject_builtins (i.e. currently everything compiled with Hy) will end up immediately pulling in most of Hy's submodules. I guess the goal is to no longer need this once Hyrule is complete? and then compiled programs would only need to auto-import the barest minimum subset of Hy

[Kodiologist]

Hyrule will eliminate the need to auto-import functions, and but not to auto-require core macros. I'm not sure how much that will help, ultimately.

[allison-casey]

Hy still desperately needs a reorganization pass to eliminate the complex dependency chains that scauligi mentioned. the whole code base is quite fragile to change as it stands.

[scauligi]

For gits and shiggles:

[allison-casey]

this graph is giving me anxiety