Make Database structure more modular: Finding Runs and specifying sample properties

From the discussion in #1071 I would like to suggest the following improvement to the data base structure:
- modularize the data discovery:
By this I mean, we only provide a `get_by_id` function in the data_set and further functions as `get_experiment_by_name` or `get_experiments_by_tags` can live in some sort of external `DataProvider`. This way we could fully separate the task of finding experiments out and have a very thin interface constituted by a single function (`get_by_id`).
For the database layout this would mean:
- remove `name` from `Experiments` table
- add new table(s) for the `DataProviders` with the `exp_id` as a foreign key and the desired attributes as rows, like name(str), tags (key/str)

- open path to integration of fabrication database
It would be beneficial if, instead of a sample name, we would store a sample id and have another table that could hold all possible sample properties.

Start by reading the discussion in issue #1071 and locating the existing database schema and data_set interface. Compare the current Experiments and sample representation with the proposed get_by_id-only interface, DataProviders tables, and sample-property table; the work is done when the modular design is implemented and its integration points are defined.

Written by the indexing model from the issue text.