token ids and src modules

[Dorran Howell]

As discussed in #269 and #270, we now have at least three different tokens to keep track of, each with their own token id: kit, wrapped tez, and liquidity tokens. This makes it tough writing entrypoints and end to end tests which interact with either checker or the tez wrapper's FA2 interfaces since we have to be careful that we specify the correct token id. Furthermore, the token id is something that should be easily configurable for collateral tokens since it is likely to be different for the various FA2 tokens which might be used as collateral.

After some discussions with @gkaracha today, we think that it would be cleaner to:

1. Use a constant value wherever possible for token ids to avoid hard-coding values and
2. Specify token ids in checker.yaml, generating the various token modules from it (tok.ml, kit.ml, lqt.ml). This comes with two additional advantages: The ability to programmatically determine token ids in tests and a more straightforward method for generating Checker's contract metadata than the current method employed in our build scripts. We can also piggy back on this change to make token scaling factors configurable through the same workflow.

[George Karachalias]

@dorranh I think that #272 addressed this issue. Are there parts that still remain to be implemented? If not, feel free to close it 🙂

[Dorran Howell]

Ah good catch, this is indeed fixed in #272