feat: tiasync: add support for vote extensions

[misko9]

closes #13

This PR adds support for chains that have vote extensions enabled. Tiablob/tiasync does not require the extended commit since a fullnode syncing from Celestia will not enter consensus and require this data. However, there are areas that Cometbft expects and verifies (to varying degrees) these extended commits.

If vote extensions are enabled for a respective height, Cometbft's blocksync ensures a well-formed extended commit is delivered. Since it does not perform signature verification, tiasync will deliver a well-formed extended commit with valid commit data, but mock extended signatures.

On a fullnode restart when vote extensions are enabled for the last block height, Cometbft also verifies the extended commit signatures for that block. A tiasync prerun method has been added to get the extended commit via p2p blocksync in order to allow Cometbft to start up successfully.

These solutions allows a chain with vote extensions enabled to not publish extended commits to Celestia, greatly saving costs for networks with large validator sets and/or large vote extension data.

Other enhancements/fixes:

1. The tiasync prerun method allows the fullnode configuration to be simplified, only requiring tiasync to be enabled. A node operator will configuration Cometbft's P2P as they would typically expect and tiasync will use those configurations for the validator networks. The fullnode Cometbft instance is then overridden to only communicate via tiasync (the p2p proxy to the validator network).
2. An unproven blockstore has been added to tiablob. This blockstore is required when restarting a node on a block with proofs of unproven blocks. On startup, these unproven blocks are inaccessible to tiablob when the proof(s) are being used and they must be stored in its own blockstore for replaying the last block. This block store will be approximately the size of all unproven blocks so it should not be very large on a chain that is successfully publishing and proving blocks. Pruning occurs whenever blocks have been proven. Snapshots will also now populate this new block store with unproven blocks instead of only being in-memory.