[CX-Marketplace] - Add the `Bundle` Complementary Builder Type

[jparr721]

Closes #3372

This PR:

Starts the groundwork for multiple fees in HotShot. HotShot needs to be able to accept multiple fees for a block to allow for multiple builders to submit bundles with requisite fees as a result of the Solver’s allocation result. Because of this, we start by creating a complementary type to the existing BuilderResponses type, and then also refactor the BlockRecv type to support the new PackedBundle type, which solves two issues:

1. The BlockRecv event tuple is large, and it would have been hard to disambiguate bid fees from sequencing fees.
2. We eventually want to support multiple fees, and the new type supports the vec1 type to allow for a guarantee that index 0 will always have a value, so there's no need to bounds check on access for the legacy behavior.

We also will need to augment the contract to how blocks are formed, this will eventually replace the existing type:

/// Builder Provided Responses
pub struct BuilderResponses<TYPES: NodeType> {
    /// Initial API response
    /// It contains information about the available blocks
    pub blocks_initial_info: AvailableBlockInfo<TYPES>,
    /// Second API response
    /// It contains information about the chosen blocks
    pub block_data: AvailableBlockData<TYPES>,
    /// Third API response
    /// It contains the final block information
    pub block_header: AvailableBlockHeaderInput<TYPES>,
}

To the new type added to the code:

/// The Bundle for a portion of a block, provided by a downstream builder that exists in a bundle
/// auction.
pub struct Bundle<TYPES: NodeType> {
    /// The bundle transactions sent by the builder.
    pub transactions: Vec<<TYPES::BlockPayload as BlockPayload<TYPES>>::Transaction>,

    /// The signature over the bundle.
    pub signature: TYPES::SignatureKey,

    /// The fee for submitting a bid.
    pub bid_fee: BuilderFee<TYPES>,

    /// The fee for sequencing
    pub sequencing_fee: BuilderFee<TYPES>,
}

This type will eventually replace the BuilderResponses type entirely but, right now, we leave it to maintain backwards compatibility in expectation that this change will be complete in a subsequent PR. This PR would have been extremely large if not broken up so, right now, this type does not change the existing logic.

This PR does not:

Change any logic, we simply wrap all existing builder_fees into bid_fees, and add an always-null sequencing_fee to every event.

Key places to review:

• data.rs
• transactions.rs

Existing tests should all pass.