Paima config v2

[SebastienGllmt]

Right now Paima configurations have a few issues:

1. They're spread across multiple files making them hard to understand
2. They're all JSON/YML data which makes it hard to reference from other places
   1.They're all string-based making type checking, value retrieval or dynamic computation impossible

To solve this, I propose we do similar to multiple tools and instead have the configuration file be a js file
The benefits are
1.We can get type safety on all of it to avoid stupid mistakes
1.We can import stuff dynamically, which allows us to get rid of the really ugly abiPath variable and just replace it with inline ABIs
1.We can refer to the configuration file directly from other places as needed

The core idea of this is that the .js file, when run, generates a JSON file that can be used for things that need JSON

Here is an example of what it would look like

// write config file

import deployedEvmAddresses from '../contracts';
import SomeFactoryAbi from '../contracts/SomeFactoryAbi';
import SomeActionAbi from '../contracts/SomeActionAbi';
import { stfInputs } from '../data-types';

const configBuilder = new ConfigBuilder();

// TODO: maybe just use the viem chain configuration system for the 'evm' type?
configBuilder
  .addNetwork({
    configName: 'Ethereum',
    type: 'evm',
    chainId: 1,
    chainUri: 'http://localhost:8545',
    chainCurrencyName: 'Test Hardhat Tokens',
    chainCurrencySymbol: 'TEST',
    chainCurrencyDecimals: 18,
    // caip-2 calculated implicitly
  });

configBuilder.registerDeployedContracts(deployedEvmAddresses);

configBuilder.addFunnel({
  configName: 'MainFunnel',
  type: 'evm-main', // key to resolve which fields are allowed

  networkName: configBuilder.networks.Ethereum, // value allowed here depends on type
  blockTime: 2,

  // note: the way this has to work from at type-perspective is that this resolves to an object
  //       { contractAddress: '0x...', chainId: number },
  //       and we check that chainId here matches the chainID of the funnel 
  paimaL2ContractAddress: configBuilder.deployedEvmAddresses['PaimaL2Contract'], // ideally, optional (as a primitive?)
  // network fields like chainId are added dynamically?
});

configBuilder.addPrimitive({
  configName: 'Base URI changed',
  funnel: configBuilder.funnels.MainFunnel,
  type: 'dynamic-evm-primitive',

  startBlockHeight: 0,

  contractAddress: configBuilder.deployedEvmAddresses['SomeFactory'],
  abi: SomeFactoryAbi, // inline the abi JSON directly? We can filter it down at runtime when parsing the config
  eventSignature: 'SomeDeployed(address)', // we can use Viem to make sure this event exists in the ABI

  targetConfig: {
    scheduledPrefix: stfInputs.baseUri,
    type: 'generic',
    abi: SomeActionAbi,
    eventSignature: 'SomeAction(...)',
  },
  dynamicFields: {
    contractAddress: 'nft'
  }
  // network fields like chainId are added dynamically?
})

notably the main problem I'm trying to solve is that the most common primitive you want is the generic primitive. However, the generic primitive right now has the worst UX and it's really annoying to work with. This change help makes the generic primitive the easiest to work with (you just import your ABI and you're done)