refactor: Add fastLaneLengthSlots to getFrameConfig interface

[tamtamchik]

PR Summary:

This PR highlights a minor discrepancy between the getFrameConfig method signature in the HashConsensus contract and its corresponding interface definition used in other contracts.

Below is the getFrameConfig method from the HashConsensus contract:

contract HashConsensus
    function getFrameConfig() external view returns (
        uint256 initialEpoch,
        uint256 epochsPerFrame,
        uint256 fastLaneLengthSlots
    ) {
        FrameConfig memory config = _frameConfig;
        return (config.initialEpoch, config.epochsPerFrame, config.fastLaneLengthSlots);
    }
}

And here is an example of an interface definition in contracts that use this method, where the fastLaneLengthSlots field is not included in the interface:

interface IConsensusContract {
    function getFrameConfig() external view returns (
        uint256 initialEpoch, 
        uint256 epochsPerFrame
    );
}

Background:

The fastLaneLengthSlots parameter was introduced in this commit. However, the interface was not updated for the following reasons:

Backward Compatibility: If the HashConsensus is updated to return additional values (such as fastLaneLengthSlots), existing contracts that rely on the IConsensusContract interface do not need to be modified, as long as they are only interested in the first two return values (initialEpoch and epochsPerFrame). The additional value (fastLaneLengthSlots) will be ignored by contracts not expecting it.

Selective Data Retrieval: In some cases, contracts interacting with HashConsensus only require specific values (e.g., initialEpoch and epochsPerFrame). Using an interface with fewer return values simplifies the interaction. This approach avoids the need to handle or store unused data, potentially reducing gas costs and keeping the code cleaner.

---

Ported from #210