Meta Issue: Extensible Cosmology #11777

(Migrated from #10673, which I closed)

• split cosmology classes from realizations #11345 : Separating all the cosmology realizations (and controller default_cosmology) to a separate file — realizations
  I've currently called this builtin, but realization might be better.

2. upgrade default_cosmology to be a registry (a la galactocentric_frame_defaults) so users can add their own cosmology realizations and set them as the default.

• change the parameters file to an ECSV (if pyyaml becomes a dependency, JSON otherwise). WIP: Auto-Import User-Defined Cosmology Realizations #11517

4.1 Add entrypoints to the realizations, so that third-party packages can add specific cosmology realizations and users can access them straight through astropy.

4.2 Also allow auto-import of user-defined realizations from a file(s).

• JSON & ECSV I/O Cosmo Unified I/O #11559
• WIP: Auto-Import User-Defined Cosmology Realizations #11517
• configuration parameter for parameter files location.

4. Enhance the Cosmology class so it initializes the default cosmology, with any user-passed modifications. This centralizes the cosmology creation process for any "perturbations" about the default cosmology. Finally a use for the base class.

   • : step 1 is Simplify Cosmology cloning logic #11515
   • : step 2 is Cosmology base class #11518

5. [Not in this PR] Add entrypoints to core, where the Cosmology classes are defined, so that third-party packages can add cosmologies and have them integrate well with the realizations machinery.

At the end, astropy will provide a core set of cosmology classes and realizations, but be highly extensible to allow user-defined realizations, and aggregate third-party cosmologies and realizations.

These PRs might also might partially alleviate the lack-of-maintainer problem. Instead of programming more Cosmology classes, we let third-party packages demonstrate user need. If a Cosmology class becomes stable & popular enough then it could be added as a built-in.