refactor: use marker trait for client types

[merklefruit]

This refactor aims to simplify the api cilent interface by moving the 15 generics into a single ClientTypes marker trait.
This trait is then implemented for the two presets exported by the library.

Note: This is a breaking API change for users who defined their own beacon api clients.

(As suggested by @DaniPopes)

[ralexstokes]

hey! this is great

I can say the current implementation was a bit of a hasty refactor to support the compile-time presets feature implementing the "presets" idea from the ethereum/consensus-specs

Another implementation (that stays a bit truer to the implementation in ralexstokes/ethereum-consensus) would simply be to surface the const generics each of these types carries. It would look something like this:

struct Client<
    const MAX_PROPOSER_SLASHINGS: usize,
    const MAX_VALIDATORS_PER_COMMITTEE: usize,
    const MAX_ATTESTER_SLASHINGS: usize,
    const MAX_ATTESTATIONS: usize,
    const MAX_DEPOSITS: usize,
    const MAX_VOLUNTARY_EXITS: usize,
    const SYNC_COMMITTEE_SIZE: usize,
    const BYTES_PER_LOGS_BLOOM: usize,
    const MAX_EXTRA_DATA_BYTES: usize,
    const MAX_BYTES_PER_TRANSACTION: usize,
    const MAX_TRANSACTIONS_PER_PAYLOAD: usize,
    const MAX_WITHDRAWALS_PER_PAYLOAD: usize,
    const MAX_BLS_TO_EXECUTION_CHANGES: usize,
    const MAX_BLOB_COMMITMENTS_PER_BLOCK: usize,
    const SLOTS_PER_HISTORICAL_ROOT: usize,
    const HISTORICAL_ROOTS_LIMIT: usize,
    const ETH1_DATA_VOTES_BOUND: usize,
    const VALIDATOR_REGISTRY_LIMIT: usize,
    const EPOCHS_PER_HISTORICAL_VECTOR: usize,
    const EPOCHS_PER_SLASHINGS_VECTOR: usize,
    const PENDING_ATTESTATIONS_BOUND: usize,
    const SYNC_SUBCOMMITTEE_SIZE: usize,
    const BYTES_PER_BLOB: usize,
>

and then we can just supply the appropriate constants when defining the crate::presets.

That being said, if the aim here is to simplify the complexity of the type signature then I think this PR is a great solution. Which do you prefer?

[merklefruit]

Which do you prefer?

Both seem like an improvement, but this PR introduces a more minimal diff by keeping all the existing types as they are, which is more ideal in my opinion

[ralexstokes]

yeah I agree :)