Define new options api interface and BE-FE options sharing strategy

[robhrt7]

Currently we break up all the settings for back-end modules and front-end modules, which makes configuration a bit more complex, especially with plugins. Proceeding with this structure, users always will need to think about where they should put config in.

I would like to merge BE and FE options, for easy sharing common parameters. If plugins uses both environments, it could have only one simple configuration:

{
plugins: {
  plugin: {
      commonOptions: true,
      feOption: false,
      beOptions: false
    }
  }
}

The problem: how to share all the setting with Front-end environment, without exposing private settings, that should not be available externally. Back-end part always have access to everything, for Front-end, only thing that stops us doing the same is privacy.

One of the solutions is to parse private storage, and strip it out on the way to Front-end:

{
plugins: {
  plugin: {
      commonOptions: true,
      feOption: false,
      private: {beOptions: false}
    }
  }
}

Where private: {beOptions: false} won't be exposed in /api/options call from the browser. But it might be not clear for plugin developers, and may cause potential leaks.

To discuss: should we expose everything by default, and hide private fields, or other way, hiding everything, and showing common fields?

After defining the solution, we will need to upgrade /api/options payload.

[robhrt7]

@cheshirsky, what do you think about it?

[robhrt7]

We decided to make all the options private by default, and allow to configure separate fields, separating manifest and actual, configurable options. Plugin options will be shared to client-side as well, and a bit later, we will define a best practice for structuring configuration.

We also will be restructuring current options object, hiding something by default, and re-grouping parts.