Refactor configuration system

[pont-us]

Currently the configuration system is a little ad-hoc, with some configuration options settable in the notebook, some on the CLI, and some on both. More configuration options (both build-time and run-time) are planned, and possibly more interfaces for xcengine/xcetool itself, so it would be nice to rationalize and future-proof the configuration system. Sketch of a refactored solution:

1. Single source of truth for configuration options, which is used to create both the in-notebook and CLI configuration interfaces.
2. Configuration settings are also written to a YAML file in the image to make them accessible at run-time. So e.g. default port could be set in the notebook. (Notebook config also could be retrieved at run-time by executing the parameters cell, but this would be inconvenience and wouldn't cover CLI options.)
3. Configuration engine uses the "single source of truth" at image build time to process any in-notebook and/or CLI options supplied by the user.

[pont-us]

Another thing to consider in this context: implement type hinting for the in-notebook configuration to improve discoverability of configuration parameters. This would probably require creation of a new xcengineconfig (or whatever) package which could be imported with no dependencies, without pulling in the whole xcengine stack.