Currently, preferencesIpc is the only way for application code to access the preferences model. This is unfortunate, because it means that main process code can essentially not access the preferences without asking a renderer to do that access for it (this is essentially what happens for telemetry, for example).

Other packages such as compass-logging transparently select the right way of accessing the underlying structures, so that they can be used through the same API in both main process and renderer processes it. We should do the same here.

Specifically, this would entail moving setup-preferences.ts to compass-preferences-model, stopping to export preferencesIpc directly, and instead export a wrapper that accesses either the preferences model singleton in the main process, or preferencesIpc in renderer processes.

This can also involve aligning diverging APIs (e.g. onPreferencesChanged vs. onPreferenceValueChanged).