Add an ss58 encoding library to entropy-protocol

[ameba23]

In order to create a session id for the signing protocol in entropy-protocol we need to be able to encode a substrate account ID as ss58.

Normally we do this with sp-core with to_ss58_check, but sp-core doesn't work on wasm.

Why is this issue relevant?

For context see this discussion: #414 (comment)

What steps are required to resolve this?

@JesseAbram suggested using ss58-registry but as far as i can see, that crate will give us the address type, but will not do the other steps involved in ss58 address encoding (eg: calculate the checksum).

If the checksum was a one liner, i would just go ahead and copy it from sp-core. But here is what to_ss58_check does internally:

fn to_ss58check_with_version(&self, version: Ss58AddressFormat) -> String {
		// We mask out the upper two bits of the ident - SS58 Prefix currently only supports 14-bits
		let ident: u16 = u16::from(version) & 0b0011_1111_1111_1111;
		let mut v = match ident {
			0..=63 => vec![ident as u8],
			64..=16_383 => {
				// upper six bits of the lower byte(!)
				let first = ((ident & 0b0000_0000_1111_1100) as u8) >> 2;
				// lower two bits of the lower byte in the high pos,
				// lower bits of the upper byte in the low pos
				let second = ((ident >> 8) as u8) | ((ident & 0b0000_0000_0000_0011) as u8) << 6;
				vec![first | 0b01000000, second]
			},
			_ => unreachable!("masked out the upper two bits; qed"),
		};
		v.extend(self.as_ref());
		let r = ss58hash(&v);
		v.extend(&r[0..2]);
		bs58::encode(v).into_string()
	}

I think it would be a bad move to copy this code as we'll run into problems if substrate change this some day.

More info about ss58: https://docs.substrate.io/reference/address-formats/

Does this change the spec? HTTP, extrinsic, or storage? Is it breaking? Clearly describe the new interface.

If we create signing protocol session IDs in entropy-protocol rather than having them passed in, then this is a breaking change

[ameba23]

Closing this as no longer imminent / relevant following #549