Relationship between tick sizes and fees in Uniswap v3-like exchanges

[sklbancor]

          **to be converted to issue -- current solution OK to fix problem at hand**

Situation

The way we are dealing with this is for historical reasons, and it is somewhat bad. To provide context: in Uniswap v3 like AMMs there is a parameter called tick-spacing that determines the size of their atomic ranges, and the original authors linked the tick-spacing to the the transaction fee. Whilst this is economically directionally sensible there is no natural relationship between tick size and fees, therefore Uniswap 3 style exchange could make changes to this relationship, including

1. they respect the Uv3 relationship between fees and tick size, but introduce additional fee tiers with their associated tick sizes that then become canon
2. they maintain a relationship between fees and tick size, but they do not respect Uv3 choices (or canonic choices introduced by others before them)
3. they do not maintain a relationship between fees and tick size

At the moment we seem to be in situation (1) which is lucky because our approach of parameterization only works for situation (1). As soon as we get to (2) or (3) we will need to find another approach, and I suggest scheduling this rather than doing it last minute.

Also at the moment we use floats as keys for a dict which I really really do not like, even if it is legal

Proposal

What I propose is the following:

1. We get rid of the fee constants; instead we agree that we always denominate fees in 1/100s of basis points or something and so they are ALWAYS ints
2. We then have a two-stage dict that associates the tick size to the fee level

TICKSIZE = {
  "<exchange>": {
      <fee>: <ticksize>,
    ...
    }
  }

This allows as to operate in scenario (2), and it also allows us to catch fee levels that are illegal for that exchange.

if we want to support scenario (3) we also need to allow for free choice of fee and tick size

Originally posted by @sklbancor in #590 (review)