flepimop internal structure principles

[pearsonca]

I'd like to move the flepimop / gempyor internals in a more loosely coupled / independently usable / hotswappable direction.

Based on discussion with @jcblemai, my understanding of the desired organization:

• in general: we should not be passing around the configuration object as much. aim to: generate it "close" to the user interface with flepimop [COMMAND] ... (roughly, in the cli.py main methods, then pass to the command handlers), the command handlers should select out the relevant bits for their particular operations and then pass those as instantiated objects to the inner workings of the tool. Put another way: we should have core library that knows nothing about the configuration context and which other people could import and use in their own infrastructure.
• want commands / actions to be defined in alongside their more core library components, rather than all in the cli.py. There doesn't appear (currently) to be a way to discover / introspect which module files have / don't click interfaces, so they still all have to be manually registered - might want to be more clever about this
• also want context parsing / validation into objects to be alongside the pertinent objects
• re these last two: these are to keep these elements sufficiently coupled. for other reasons (library dependency sprawl, e.g.), might want them looser. balance of pro/con TBD

[pearsonca]

Regarding the config object: it is both a package-level variable and an object that gets passed around, which seems like the worst of both worlds.

Some of the problem here seems to be what we allow as entry points to the library functionality. To prune the amount of config passing, we're going to have to 1) reduce/change the "public" interface to gempyor internals -- this should be offset by refinements / improvements to the CLI, 2) overhaul what's getting passed / built where, ideally with 3) actual unit testing of what's supposed to do what.