Consider Making Repo Less "Magical"

This is not a direct action item, nor is it high priority. This is basically a group of retrospective thoughts on the design direction of this repo.

This repo does a lot of things automatically with no real explanation to the user: just set up your conf file and launch the hutch-python launcher script. We'll call your beamline and experiment files at some point and make the RE for you. This works reasonably well, but it has the following issues:

• It is difficult for the end-user to differentiate between issues that come from this repo itself rather than from the user's code, since the code paths are obfuscated. How does a user debug configuration issues when they can't add debug handlers before/after/during the configuration loading steps? When exactly is my code being loaded anyway? This is mitigated by strong built-in debugging tools, but they are all custom which makes it awkward to work with.
• It is difficult for the end-user to know where different objects are being defined and how these objects are being configured.
• This repo does not leverage standard tools like ipython profiles at all. Users who are familiar with these sorts of tools will not have a starting point for working with hutch-python and users who start with hutch-python will not gain experience with these standard tools.

I'd like a reimagining of this repo that relies on ipython profiles and is predicated on a clear initialization e.g.:

import hutch_python.start
hutch_python.start(debug=False)

With easy to locate sub-functions so the user can break this out and debug their configuration issues.

Start by tracing the hutch-python launcher script and configuration-loading flow described in the issue. Compare the current initialization behavior with the proposed importable hutch_python.start entry point and IPython profiles. Done would mean a defined redesign with clearly separated initialization functions and a documented way to debug configuration issues.