feat: basic DIP structure (#489)

Fixes KILTprotocol/ticket#2550.

**This PR will merge the changes into the `aa/dip` branch, which will be
the base branch for all the future DIP improvements until we reach a
version that we can merge into `develop` and deploy on some testnets in
the Peregrine runtime.**

## Base structure for DIP

This PR contains the following components:

* A pallet to send identity information to one or more destinations (DIP
sender)
* A pallet to receive such identity information from a source (DIP
receiver)
* A support crate that contains common (versioned) types, in future also
traits and auxiliary functions, if needed
* A template project consisting of 1. a template runtime for the
dip-sender, with its node counterpart, 2. a template runtime for the
dip-receiver, with its node counterpart, 3. an example XCM integration
test using [XCM emulator](https://github.com/shaunxw/xcm-simulator) (not
simulator) which connects the two template runtimes with a local Rococo
relay chain.

### Design

The current version assumes that anyone on the sender chain can dispatch
identity information on some target chain (with which there exists an
open HRMP channel). Ultimately, all the fees for dispatching the message
and process it on the receiver side will be paid by the extrinsic
submitter on the target chain. Right now, the submitter only pays for
the extrinsic dispatch on the source chain, and the chain itself uses
its own balance (liked to its sovereign account) on the target chain to
pay for the `Transact` execution. The `Transact` operation that
interacts with the `dip-receiver` pallet on the target chain has an
`OriginKind::Native`, so that there is no way for any user on the source
chain to dispatch such messages.

Right now, the basic structure and the templates use defaults for
everything, from proof generation to proof verification. One step at the
time, all these defaults will be replaced with the actual features.
Nevertheless, for two chains that have the same concept of `Identifier`
and `AccountId`, it is already possible to demo the complete e2e flow.
For the sake of our demonstration, the flow would go as follow,
**assuming that both the source and target chains are registered as
parachain on the same relaychain**:

1. The source chain requests to open an HRMP channel with the target
chain
2. The target chain accepts the request and the channel is open
3. The target chain issues some funds (enough to cover the demo use
case) to the sender chain's sovereign account
4. A user on the source chain creates a DID with a single authentication
key
5. The same user (but could be anyone else), calls the extrinsic on the
`dip-sender` pallet to send the merkle root of the DID to the target
chain, paying for the dispatch fee
6. The source chain sends the information to the target chain
7. The user calls the `dispatch_as` extrinsic of the `dip-receiver`
pallet which is deployed on the target chain, providing a merkle proof
of their DID document + details on the source chain. For now this check
always returns true.
8. Inside, the `dispatch_as` has a nested call which is dispatched with
the new `DipOrigin`, which pallets can now use if they expect extrinsics
to be DID-authorized.

## What's coming

I created tickets for each of the next steps, under the DIP milestone.
The tickets will take care of:

* Adding benchmarks and weights
* Introducing proper error handling
* Introducing proper DID signature verificaiton on the target template
chain (right now it's just a default behaviour)
* Introducing proper merkle proof generation (I tested that it works,
but removed those pieces from this PR for the ease of understanding)
* Introducing proper merkle proof verification (same as above)
* Adding an emergency brake in the sender pallet to stop dispatching
messages to a specific destination, e.g., if the sender sovereign
account on the destination chain does not have any more or if the
`Transact` encoding would fail
* Adding support for metadata beyond the simple DID details, e.g., proof
expiration time, etc.
* Replacing user-provided weights and assets with per-chain
configurations stored in the sender pallet
* More comments (I can work on this first if the code as it is it's too
hard to follow)
* Adding support for version negotiation. There is a basic concept of
versioning right now, but it can and should be expanded and improved.
* More unit and integration tests.

Probably more tickets will come out of this work, and will be tracked
separately in the same or in future milestones.

## How to test

A basic integration test of the two template runtimes is present in the
`dip-templates-xcm-tests` crate, inside the
`dip-template/runtimes/xcm-tests`. It can be run as usual with `cargo
test -p dip-templates-xcm-tests`.

.gitignore

@@ -15,7 +15,4 @@
 # ignore vscode settings
 .vscode
 
-# Custom Polkadot-js apps types
-pallets/did/src/custom_types.json
-
 **/__pycache__