Light client module interface for ICS

This issue is a work-in-progress version of the interface for a light client module.

## Serialization format

Module programmers will use **two types of serialization format**.

Let's assume that chain A has light clients of chain B, and chain C. Chain B is using MessagePack to serialize data. Chain C is using ProtoBuf to serialize data. Let's think of `verifyChannelState` in the light client. The handler module passes the expected `ChannelEnd` value to the function. So we need a serialization method of how to serialize the `ChannelEnd` (this is the serialization type 1). To verify the `ChannelEnd` struct, each light client serializes the `ChannelEnd` data to each chain's serialization format (MessagePack and ProtoBuf). This is the serialization type 2.

### Serialization type 1

We will use JSON.

The handler module will send several types of data to the light client modules. If we use "RLP" for this serialization format, each module's developer should implement decoder of RLP. To reduce the light client developer's work, we (Junha and I) concluded to use JSON format in this case.

If the module system supports a default serialization method of simple struct types, we can use it instead.

### Serialization type 2

Each light client must implement each chain's serialize code.

## Interface functions

### Query

```rs
fn query_client_state(client_id: String, block_number: Option) -> Bytes
```

```rs
fn query_consensus_state(
client_id: String,
counterparty_block_number: u64,
block_number: Option,
) -> Bytes
```

### Transaction

```rs
fn create(id: IdentifierSlice, _consensus_state: Bytes, header: Bytes)
```

```rs
fn update(id: IdentifierSlice, header: Bytes)
```

### Functions can be called from other modules

```rs
pub fn query_latest_height(id: IdentifierSlice) -> u64
```

```rs
pub fn verify_connection_state(
client_identifier: IdentifierSlice,
proof_height: BlockNumber,
proof: Bytes,
counterparty_connection_identifier: IdentifierSlice,
connection_end: &ConnectionEnd,
)
```

```rs
fn verify_channel_state(
id: IdentifierSlice,
proof_height: BlockNumber,
proof: Bytes,
port_identifier: IdentifierSlice,
counterparty_channel_identifier: IdentifierSlice,
channel_end: &ChannelEnd,
)
```

```rs
fn verify_packet_data(
id: IdentifierSlice,
proof_height: BlockNumber,
proof: Bytes,
counterparty_port_identifier: IdentifierSlice,
counterparty_channel_identifier: IdentifierSlice,
sequence: &Sequence,
packet_commitment: &PacketCommitment,
)
```

```rs
fn verify_packet_acknowledgment(
id: IdentifierSlice,
proof_height: BlockNumber,
proof: Bytes,
port_identifier: IdentifierSlice,
channel_identifier: IdentifierSlice,
sequence: &Sequence,
acknowledgment: &Acknowledgement,
)
```

```rs
fn verify_packet_acknowledgment_absence(
id: IdentifierSlice,
proof_height: BlockNumber,
proof: Bytes,
port_identifier: IdentifierSlice,
channel_identifier: IdentifierSlice,
sequence: &Sequence,
)
```

```rs
fn verify_next_sequence_recv(
id: IdentifierSlice,
proof_height: BlockNumber,
proof: Bytes,
port_identifier: IdentifierSlice,
channel_identifier: IdentifierSlice,
next_sequence_recv: &Sequence,
)
```

Das Issue nennt keine Dateien, Tests oder Einstiegspunkte. Beginne damit, die Abstraktionen für den Rust-Light-Client und die Modul-Schnittstelle zu finden, und vergleiche sie anschließend mit den vorgeschlagenen Signaturen für Abfragen, Transaktionen und Verifizierung. Die Aufgabe ist abgeschlossen, wenn die Schnittstelle und das Serialisierungsverhalten abgestimmt, implementiert und durch geeignete Tests abgedeckt sind.

Vom Indexierungsmodell aus dem Issue-Text verfasst.