Track package organization cleanup after rc7

[iskandr]

Goal

Split the bulkiest modules into responsibility-focused submodules so the package is easier to navigate and reason about, while preserving public import compatibility during migration.

Ground Rules

• One refactor PR per scope.
• Each PR bumps to the next release candidate version: rc8, rc9, rc10, rc11, etc.
• Keep old public modules as compatibility shims/facades where module paths might matter.
• Add import-shim/schema tests for each move so downstream code keeps working.
• Avoid behavior changes; these should be mechanical organization PRs.

Planned Order

• rc8: move command modules under mhcflurry.cli #307: rc8: expand mhcflurry.cli and move command modules under it.
• rc9: split local_parallelism into mhcflurry.parallelism #305: rc9: split mhcflurry/local_parallelism.py into mhcflurry/parallelism/.
• rc10: split class1_neural_network helpers #308: rc10: split helper/model/training code out of mhcflurry/class1_neural_network.py without moving public class paths yet.
• rc11: split class1_affinity_predictor helpers #306: rc11: split helper code out of mhcflurry/class1_affinity_predictor.py while keeping Class1AffinityPredictor as the facade.

Compatibility Risks

• Console entry points in setup.py must continue to work.
• Public imports from mhcflurry.local_parallelism, mhcflurry.class1_neural_network, and mhcflurry.class1_affinity_predictor should continue to resolve during the transition.
• Moving public classes directly can affect pickle/module paths and serialized metadata assumptions; avoid that until a dedicated compatibility audit is done.