Reduce the overhead of seal in light clients

## Background
Light clients (both standalone and ICS) utilize the concept of 'Update header', which is a set of data that is enough to update a light client's best header. (In abstract terms, we call this 'update of client state'.)
Currently Foundry's `UpdateHeader` contains `new_header`, `validator_set`, and `seal_for_current` (for `new_header`).

We don't actually need all fields in the header for light clients. For example, `author`, `parent_hash`, `extra_data`... and **even the `seal`**
However, we must provide them to light clients since they contribute to the block hash, which will be verified by the `seal_for_current`.

As you can see, `UpdateHeader` contains **two seals**.

## Problem
You might think it's tolerable, but it's not. It has a problem with ICS.
Of course ICS's light client will have the same problem of having two seals, but the worse part of doing this is that the `UpdateHeader` in IBC will be recorded in the transaction, and ultimately, in the block.
This means that a full node will carry approximately 3 seals per block if it is Foundry-Foundry IBC and each's chain has similar block generation rate.
- one for its own block
- one for `update_header.new_header.seal`
- one for `update_header.seal_for_current`

## How to solve
We can change the hashing scheme of our header to:
`hash(header.a1, header, a2, .... , hash(header.b1, header.b2, ...))`
where `a#`s are fields that the light client actually uses, and `b#`s are not. (e.g `seal`)
This forms a 2-depth Merkle tree and the `UpdateHeader` will contain only `a#`s + `hash(header.b1, header.b2, ...)`, not the whole `new_header`.

## BLS
It might be 'tolerable' if we decided to introduce BLS to master.