Proposal: Multiblock encoder interface

We're running into more and more cases where BlockEncoder interface just does not fit the bill:

1. With IPNFT geared towards NFTs we've discovered that NFT metadata can easily exceed 1MiB size which would hinder our ability to serve such blocks on gateway etc....
2. With new UnixFS code we basically want pass file and get set of blocks with a root back.
3. Now with UCANs we want to pass auth chain and produce block per link in chain.

I am sure I'm forgetting some and we are likely to encounter more use cases where we want to turn some input into a DAG represented by many blocks. Which is why I would like to propose adopting following interfaces:

export interface SyncDAGEncoder<Code extends number = number, T extends unknown = unknown> {
  encoder(data:T): IterableIterator<{ code: Code, bytes: Uint8Array }>
}

export interface AsyncDAGEncoder<Code extends number = number, T extends unknown = unknown> {
    encoder(data:T): AsyncIterableIterator<{ code: Code, bytes: Uint8Array }>
}

export type DAGEncoder<Code extends number = number, T extends unknown = unknown> =
  | SyncDAGEncoder<Code, T>
  | AsyncDAGEncoder<Code, T>

Last block would be a DAG root block (which is natural due to hash linking)

Such interfaces would cover all above use cases. Additionally we could make all our block codecs implement these interface too making them compatible.

Start by reading the existing BlockEncoder interface and the block codecs mentioned in the proposal. Compare their current contracts with the proposed synchronous and asynchronous DAG encoder interfaces, including multi-block output and the final root block. Done requires an agreed interface design and a clear plan for compatibility with existing codecs.