Polkadot integration

[svyatonik]

I didn't wanted to open this PR until we have everything else ready for Polkadot <-> Kusama , because it is another bunch of code to maintain. I also had doubts about bp-polkadot and bp-kusama crates - probably they should be based on polkadot-primitives / polkadot-runtime-common. Opening now on request.

[tomusdrw]

I didn't wanted to open this PR until we have everything else ready for Polkadot <-> Kusama , because it is another bunch of code to maintain.

I agree, but IMHO it's going to be easier to keep Polkadot<>Kusama integration up to date (instead of going through your fork).

I also had doubts about bp-polkadot and bp-kusama crates - probably they should be based on polkadot-primitives / polkadot-runtime-common.

I also wasn't sure what the best place to put them:

1. Initially I thought they don't belong to the bridges repo at all,
2. but then I realised it will make it easier for others to build bridges to Kusama or Polkadot.
3. Having them depend on polkadot/kusama primitives would be good, but if they stay in this repo it creates circular repo-deps problems.

Currently I think that:

• Long term - these crates should rather be part of polkadot repo (see medium term for details) and they should depend on the same primitives that the runtime of these chains depend (careful with versioning).
• Medium term - they should stay in bridges-common but all chain-specific stuff should be extracted to a separate directory (see Make relayer loops generic #2491 or Make relay (easy) configurable for other chains #61). As part of our "librarification" efforts, there should be a clear separation between generic components, chain-specific primitives and chain-specific implementations with clear rules how they can depend on each other. I imagine this would be 3 different top level directories: generic, chains/<chain>/primitives, chains/<chain>/relay and the last two would later on be extracted to chain-specific repos (added Split generic and chain-specific code #544 for this)
• Short term - it's fine as it is currently, we should just be careful to not add any external chains in the same way (like adding constants to primitives/runtime/src/lib.rs for instance).