Tuner refactoring

Now tuner uses metrics that not compatible with composer metrics. Also it has a monolith structure.

What should be done:

• Union metrics for composer and tuner
• Make tuner more flexible using decomposition
• Implement self._objective as separate module
• Refactor view of model parameters. Now they become too complicated to store them into dict (see #862)

UPD (from @gkirgizov) Additional subtasks:

• HyperOpt.get_metric_value seems to duplicate logic of PipelineObjectiveEvaluate that’s concerned with how to validate the model – so it’s better to use it instead.
• Abstract Tuner to arbitrary Graphs. The only place where the specifics of Pipeline are required – is for evaluation of objective. But, I think, currently this can be encapsualted with Objective/ObjectiveEvaluate classes.

Regarding 1st and 3rd points by Valera, possibly Objective class is useful here.

[nicl-nno]

Наверное единственный случай, который приходит в голову - когда у композера несколько критериев, а для тюнера актуален только один. Но это можно на стороне тюнера обрабатывать.

[Dreamlone]

у нас есть sequential тюнер, который нигде, кроме теста не используется

Это не совсем так. Последовательный тюнер имеет важную особенность: он может настраивать отдельные узлы, а не пайплайны целиком. Такая функциональность например нужна при локальном анализе чувствительности, который реализован в фреймворке версии ещё Иры. Если решите от последовательного избавляться, то стоит вынести эту функциональность в отдельную сущность