Driver support - support multiple version of evitaDB

[lukashornych]

Within #94, base ground for this support was set in form of internal evitaLab data layout and the Value wrapper. Currently, we will have a single driver built on top of gRPC-web of the latest evitaDB and we need to think about how will support future versions. Two possible version come to mind:

• create separate implementation of driver with converter for each evitaDB version that breaks an API
  • this will create lot of duplicate code, where possible driver bugs will be duplicated
  • over time, the browser will probably need to download lot of data from server (idk if tree shaking will help here if we will need the driver dynamically at runtime)
• create single driver implementation where the logic of supporting multiple APIs will be directly in the driver and converters (possibly using ifs and switches)
  • will not bloat in size as much as the first option
  • there will be much less duplicated code
  • it will be harder to maintain multiple versions using ifs and switches without breaking support of older drivers

There is also problem with the actual generated gRPC code, which would be kind of duplicated as well and would bloat the code base as well.

I personally don't like any of these solutions.

Second part will be to display useful information to users of evitaLab about supported features for a current evitaDB server #152.

[lukashornych]

Maybe we should get rid of the Value wrapper around properties and define default for unsupported properties directly in the converter in driver. The UI layer would be still handled as mentioned in #152 .