Support GHC-8.2.2

[chshersh]

We can implement all pairwise DivRat type family instances (it's the only instance we need according thi type signature of toUnit function) and put our implementation inside -XCPP macro for GHC-8.2.2. This requires to write O(n^2) instances though...

This also should allow us to build o-clock with stack and introduce to our packages earlier. Also we need to define *Units manually, we can't use * and / type families.

[vrom911]

@ChShersh we also won't be able to use % because it uses Normalize in it. How to handle this issue without %? :thinking:

[chshersh]

@vrom911 You're absolutely right. Users of GHC-8.2.2 will have extremely short range of features of o-clock library. They can use only predefined in library units, then can't use % and similar type families. They can live only in context with available KnownRat and DivRat type families. And we also need to add some pragmas to / type family (only Rat / Rat case can be supported).

So we won't be much better than time-units in that case, as you might guess. But the motivation behind this issue is to start using this o-clock in our libraries sooner. Otherwise we can't use o-clock for 3 or 4 months from now, which makes me sad :disappointed: Yes, we can't create our own time units. But we don't create them in log-warper and serokell-util anyways. Using toUnit and threadDelay should be sufficient.

So, this is a trade-off between really ugly code and number of features and delivering package to users sooner...

Another problem we need to solve is to support conditional compilation of README in cabal file, because we won't be able to build it with with stack...