Split hyperparams tuner into a separate lib and combine with UniOpt

[KOLANICH]

What would you like to be added: https://gitlab.com/KOLANICH/UniOpt.py

Why is this needed: In UniOpt.py I have implemented the framework which architecture have allowed me to easily wrap 3rd-party hyperparams tuners libs easily (more than 15 backends). Some of them are already present here. Some are not. Also the architecture like in UniOpt is not present here. Unfortunately I don't have much time for now to develop that project and I definitely have failed in its promotion. Also each time I use it I update all the libs wrapped by backends, and usually a few break because their maintainers have failed to provide enough of stable API for the needs of UniOpt, so I have to tinker with the libs internals.

Without this feature, how does current nni work：I guess (since I don't use it yet) pretty fine.

Components that may involve changes: pynni

Brief description of your proposal if any:

1. Separate the abstraction layer for hyperparams tuners into a separate lib with minimal mandatory dependencies.
2. Read the guide to UniOpt architecture. Take the code and look at it carefully. Decide what it lacks. Decide what your lib lacks.
3. Take the architecture from UniOpt and implement the features of this lib you lack in UniOpt, keeping in mind the following goals I had when I have been developing it:
   a. no heavy mandatory dependencies that are not already present on every system. So no webservers, JavaScript libs and tensorflow in the main package. This means I should be able to run an app using a wrapper for an optimizer without installing any dependencies unneeded for my use case.
   b. no mandatory databases other than SQLite; more precisely, no Mongo, PostgreSQL, MariaDB and other large stuff of this kind. No external daemons and webservers in this lib. I should be able to just have a single python file and just import this lib into it and just use it. No preparative actions should be needed, such as starting daemons or configuring and securing the database servers.
   c. all the hyperparameters tuners should be implemented in standalone packages.
   d. pickles shouldn't be used to store intermediate results. In fact I have developed a lib for wrapping key-value storages (currently only SQLite and LMDB backends are implemented + some compression algos + storage of records using various serialization formats depending on configuration) and utilize it.
   e. universality. all the distributions are supported by all backends. Efficiency may vary, but all the overhead of computing ppfs is negligible compared to a single hyperparams tuning iteration.
   f. one of the essential goals of that project is metaoptimization.
4. Read the issues and consider implementing them ;)