Decouple rocksdb dependency from ethcore

[sorpaas]

This decouples tsdb_rocksdb from ethcore, getting us one step closer towards #7865.

There're three places where ethcore was dependent on rocksdb.

1. ClientService database. The DB opening logic is moved to Parity CLI, and Arc<KeyValueDB> is directly passed to it.
2. Snapshot restoration. This requires opening a new DB on the fly. Thus the solution I got is to create a KeyValueDBHandler. This embeds predefined configs (if any), and exports an open function which can be used to open a DB at a given path.
3. Convertion from config DatabaseCompactionProfile to rocksdb CompactionProfile. This is only used by Parity CLI, so it's just moved there.

For this change, we do have several additional trait objects. But given that we are already using Arc<KeyValueDB> in many places, I don't think this would be any big deal.

[tomaka]

LGTM

[tomaka]

This is off-topic for this PR, but eventually for #7915 the code for snapshots should be refactored in order to remove the notion of Path from it (since we shouldn't depend on a filesystem within the browser). That's not a trivial change though.

[sorpaas]

I realized that there's an indirect dep on kvdb_rocksdb through migration. That crate, however, is not used anywhere in ethcore. So I simply fixed it by removing the dep.

I double checked. And at least from the compilation logs we indeed don't have kvdb_rocksdb dependency on ethcore this time.

[rphmeier]

eventually for #7915 the code for snapshots should be refactored in order to remove the notion of Path from it

Yes, a SnapshotStore trait which can be provided by a crate upstream would be useful for that.