Implement API Parameter Facade

[gkirgizov]

While doing aimclub/FEDOT#852 I came up with a design of a better Parameter system. The idea is to make Facade for all different parameter dataclasses. This will allow isolate external API from changes to actual parameter dataclasses.

Requirements:

• Facade should work on sub-categories (now we have 3: infrastructural ComposerRequirements, PipelineComposerRequirements, GraphOptimizerParameters)
• Unique names check (parameters from different categories shouldn't have same names)
• Support for new categories without additional work (imagine some CustomOptimizerParams)
• Facade must support init from flat dictionary of parameters (e.g. user povides different parameters from diffeernt categories in a single dictionary) --- btw this will allow refactoring ApiParams with its logic of divide_parameters
• Updates to underlying fields in dataclasses should be hidden behind common facade of get/set (by reimplemented getattr/setattr/hasattr)
• Strictness feature: only params explicitly marked as "mutable" can be modified; others are frozen by default
  e.g. possibly implement this by a decorator on dataclass fields @mutable_param
• Unique names check (parameters from different categories shouldn't have same names)

Usages could look like:

• Init with categories specified as kwargs (should work for arbitrary kwargs, custom_optimizer_params is an example).:

ParameterRepository(requirements=ComposerRequirements(),
                                   optimizer_parameters=GraphOptimizerParameters(),    
                                   custom_optimizer_params=SomeDataclassWithUserParams())

• para_repo.init_from_parameters(api_params: dict) should automatically distribute all parameters to appropriate subcategories
• 2 ways for accessing parameters should work: for example, for pop_size both param_repo.pop_size & param_repo.optimizer_parameters.pop_size

[maypink]

seems like this issue was written for FEDOT, not GOLEM