New currency type

[gianfra-t]

Closes #334.

The new type CurrencyId::Token(u64) was added to spacewalk here.

The new currency type is disabled to zenlink conversion functions.

[ebma]

Thanks for the nice description of the PR @gianfra-t.
It seems like we only have a choice between two 'easy' solutions:

1. we disallow using CurrencyId::Tokens in Zenlink pools completely or
2. we limit it to the CurrencyId::Tokens that fit into one byte, like you implemented it.

Everything else is probably more complicated because we need to change the ZenlinkLPToken type.

It might be worth discussing these two approaches before we choose one over the other. For now, I would actually vote to go for approach 1) because this way we still have time to think about the 'ideal' approach until we actually need it. If we use approach 2) and a pool is created with this we might limit ourselves in the future if we choose to come up with some fancy custom derivation function of the ID or whatever.

What's your opinion on this @gianfra-t? Maybe also @b-yap, @bogdanS98 and @TorstenStueber

[gianfra-t]

If we are not interested in using Zenlink with these new currency type now, then I also think it is better to just not allow it and in the near future think of another way to derive the IDs not just for this new type but for other types that we could add, according to our future needs.
Because even if we change the internal type of CurrencyId::ZenlinkLPToken(u8, u8, u8, u8) to u256, we will still be limited by the 2 byte representation of the asset_index shared between all currency types.

[ebma]

True. Alright then let's completely disallow using Token for Zenlink pools and postpone thinking of a derivation once needed.

[ebma]

LGTM overall