Refactor away `composer.core`

Refactoring away composer.core will help organize the imports (and thus API reference). For example, the logging base class is in composer.core, but the logger hparams base and logger implementations are in composer.loggers. This complicates the imports, leads to circular dependencies, and reduces the docs readability (since now one must look in two different places for the docs).

Instead, would it be possible to refactor away composer.core? I am thinking of a refactor like the following:

• composer.core.algorithm -> composer.algorithms.base
• composer.core.callback -> composer.callbacks.base
• composer.core.data_spec -> composer.datasets.data_spec
• composer.core.engine -> composer.engine.engine (new module for composer.engine)
• composer.core.evaluator -> composer.trainer.evaluator (depends on #329)
• composer.core.event -> composer.engine.event (new module for composer.engine)
• composer.core.precision -> composer.types.precision (new module for composer.types)
• composer.core.profiler -> composer.profiler.profiler (addressed in #422)
• composer.core.serializable -> composer.types.serializable (new module for composer.types)
• composer.core.state -> composer.engine.state (new module for composer.engine)
• composer.core.surgery -> composer.utils.surgery
• composer.core.time -> composer.time
• composer.core.types -> composer.types.types (new module for composer.types)
• composer.core.logging -> composer.logging

Because of integrated core is into the best of the codebase, it would probably be best to move one file per PR.

CC @jbloxham @anisehsani @bandish-shah @ajaysaini725

[ravi-mosaicml]

The big flag I see here is the interaction between algorithms/callbacks and engine. The algorithm API depends on engine.State, but algorithms themselves are also in the state. Could we just remove algorithms and callbacks from the state?

Yes! See https://github.com/mosaicml/composer/issues/155

[mvpatel2000]

Closing – moved to JIRA and some of this we won’t do