[spec proposal] Default BidTrace Updated to Support Timestamp and ExtraData

Context:

Currently, the _relay/v1/data/bidtraces/proposer_payload_delivered_ endpoint returns a `BidTraceV2` object that does not include a `timestamp`. This becomes a problem when one tries to analyze the impact of time on block proposals. As discussed in [[1]](https://github.com/flashbots/mev-boost/issues/111) and [[2]](https://efdn.notion.site/ROPs-RIG-Open-Problems-c11382c213f949a4b89927ef4e962adf?p=385f0f6279374a90b52bf380ed76a85b&pm=s), time impacts proposers' incentives, and correct analysis can help us better understand how the game is played.

I'm currently working on finding the unrealized value (UNREV) in payloads delivered through mev-boost. Since it is not always the case that proposers pick the (latest-delivered -> as only the latest submitted block of each builder matters) most valuable block available in any relay, UNREV emerges.

Although one reason for UNREV can be a proposer being irrational (in the sense that not always aiming to maximize his utility, e.g., because he only wants to work with a specific relay), another reason is the **timing/availability of blocks**. It is highly possible that a proposer had accepted a block too early, exposing UNREV. For example, in slot 4,849,684, the [delivered payload](https://boost-relay.flashbots.net/relay/v1/data/bidtraces/proposer_payload_delivered?slot=4849684) paid 0.06 ETH. One second later, a [block offered](https://boost-relay.flashbots.net/relay/v1/data/bidtraces/builder_blocks_received?slot=4849684) 465 ETH (0x18ce78328850d8de2f9d4c6f3fbafdd3ae143b97a9860f8b8b78ad5ac7606167).

With the current endpoints (_proposer_payload_delivered_ and _builder_blocks_received_), one cannot do a complete UNREV analysis for each block as:
- _builder_blocks_received_ only returns a subset of blocks received. If every relay offers their complete block data like [Flashbots](https://flashbots-boost-relay-public.s3.us-east-2.amazonaws.com/index.html) does, then this issue can be resolved.
- _proposer_payload_delivered_ returns a `BidTraceV2` object that does not include a `timestamp` (unlike `BidTraceV2WithTimestamp`). One can try to find the same block through _builder_blocks_received_ endpoint and use the timestamp there but I'm not sure if the timestamp of the delivered payload would be the same as the submitted builder block's.

Changes:

1. Introduces `BidTraceV3` which inherits from `BidTraceV2WithTimestamp` and adds an `extra_data` field as proposed by @metachris .
2. _relay/v1/data/bidtraces/proposer_payload_delivered_ and _relay/v1/data/bidtraces/builder_blocks_received_ endpoints both return a `BidTraceV3` now. However, it is open to discussion whether both should return the same `timestamp` for a given block.

Start with the proposer_payload_delivered and builder_blocks_received endpoints and the BidTraceV2, BidTraceV2WithTimestamp, and proposed BidTraceV3 types mentioned in the issue. Review the linked discussions and comment thread before changing the API, since the timestamp behavior between endpoints remains open. Done requires an agreed specification for timestamp and extra_data responses.

Written by the indexing model from the issue text.