Refactor feature testing for spec tests

[jimmygchen]

Proposed Changes

• Simplify logic to set up feature tests in preparation for new PeerDAS test updates, and supporting testing multiple features.
• Add docs to FeatureName usage.

Additional Details

Removed previously hard coded EIP7594_* constants, and specify the feature tests at the handler level, this is more flexible, and allows for multiple features to be developed in parallel. For example:

impl<T, E> Handler for SszStaticHandler<T, E>
where
    T: cases::SszStaticType + tree_hash::TreeHash + ssz::Decode + TypeName,
    E: TypeName,
{
    fn is_enabled_for_feature(&self, feature_name: FeatureName) -> bool {
        feature_name == FeatureName::Eip7594
    }
}

When running a test for a feature, tests used to be written this way:

SszStaticHandler::<DataColumnSidecar<MainnetEthSpec>, MainnetEthSpec>::deneb_only()
    .run_for_feature(ForkName::Deneb, FeatureName::Eip7594);

This is quite verbose and may lead to inconsistency between tests. This has been modified to specify the fork at the FeatureName level, so the fork used is only specified once in the feature_name.fork_name() function.

SszStaticHandler::<DataColumnSidecar<MainnetEthSpec>, MainnetEthSpec>::deneb_only()
    .run_for_feature(FeatureName::Eip7594);

[jimmygchen]

@michaelsproul @pawanjay176 would you mind reviewing this since you're both working on spec tests on electra? Thanks!

[jimmygchen]

FYI I'm working on the PeerDAS spec tests for alpha.10 as part of #6736.