Per-Device {instance,class} user-configurable settings

Context

There are a certain number of per-ophyd.Device configuration settings that users will never be happy with our choice of defaults. While discussing this, our primary example has been device tab whitelists.

As different users have different (legitimate) needs and preferences, @ZLLentz and I came to the conclusion that it's sensible for us to:

1. Allow the user to configure these without our intervention or a bug report/pull request/release cycle
2. Provide a general framework for these configuration settings.
   • Our goal with the framework should be the ability to support any of the following that we agree would be good to include - even if those aren't added on day 1.

User-configurable settings

Some potential things that we would add:

• Tab completion settings
• Kind settings (a configuration file overlay, of sorts)
• User interface icons
• Preferred user interface layout or display filename potentially (for device.screen())
• Tweakable device representations (@ZLLentz has an ophyd branch sitting somewhere with Jinja2-based reprs of devices. These templates could be stored in code as defaults and updated as part of config files)
• Device name aliases (then again, rereading https://github.com/pcdshub/hutch-python/issues/213 I somewhat prefer that)
• Preset positions (we already have a supported YAML format for this; I think we will decide to leave it alone)

Defaults

• We should provide a configuration with sensible defaults.
  • Good settings shared among many hutches could make their way back into the defaults.
• It should be possible to inherit from and modify the default configuration.
  • This indicates we should have some ability to merge any/all configuration settings in a standardized way

Format?

Providing a configuration file of a common format (explicitly not Python code) such as JSON or YAML seems to be superior for the following reasons:

• Easier to generate from code
• Easier to validate from code
• Less tied to API changes (but not entirely shielded, of course)
• Syntax errors or API changes won't break loading entirely

Device classes and instances

Why support classes as well as instances?

• Requiring the user to copy/paste configuration for every instance of EpicsMotor would be nonsensical (and generate a large config file, at that)

Why not just support classes and not instances?

• Our goal in the end is to provide granular configuration for each and every device.
• It's impossible to confidently say "the user will never want different settings for two of the same device class". (We also haven't figured out exactly all of the configuration settings we'd like to support yet, at that)

Inheritance?

Questions for now, as this requires more discussion:

• How does inheritance apply to configuration?
• In some cases, we may want to inherit and add to base class configuration
• In some cases, we may want to start from scratch
• Merging configuration from an inheritance tree could be messy.
• To what level do we want to support this without it becoming too confusing to find out where settings are coming from? Is there a middle ground or is it all-or-nothing?
• For ophyd.Kind specifically - how do you deal with conflicts?
• What implications are there for an ophyd.Component which has a class/instance configuration, and when the parent device has conflicting class/instance configuration settings?

Tooling

We should provide some additional tooling that performs the following:

• Configuration validation
• Generating defaults
• Merging configurations
• Generating ophyd.Device Kind trees so that the user can tweak them easily

No implementation files, tests, or entry points are identified. Start by resolving the configuration format, class/instance matching, inheritance, merging, validation, and defaults described here; done means an agreed, implementable framework with supporting tooling and tests.