support `SN_MAIN` and `SN_SEPOLIA`

[rkdud007]

currently indexer using this as chain id: 1, 11155111, 137, 280, MADARA_PRAGMA, STARKNET, SN_SEPOLIA, 300, 11155420, 421614

meaning, we have to change type u64 to string to be compatible. I'd suggest we first reconsider if this the best way to go for chain_id (e.g can't we unify into integer for everything for intermediate representation? ) and if go for string approach like indexer, need to refactor these parts in our system :

1. intermediate chain_id representation : ProviderConfig
2. json file input/output as string representation : instead of 1 -> "1"
3. dry run, fetch key chain_id representation: same context as above, dry_run_output.json should return string type

update actually we probably need to think of way to map somehow into integer. reasoning for this is, we using chain_id field also in datalake definition, which defined in solidity, cairo both.

idea : what if we keep integer, and instead of using STARKNET or SN_SEPOLIA, we turn into ascii -> hex represent -> integer e.g 0x534E5F5345504F4C4941 -> 393402133025997798000961 (SN_SEPOLIA) , 0x535441524B4E4554 -> 6004496024898258260 (STARKNET) as this all fit into u256 even 1felt (252)

note that above suggestion is about intemediate representation of chain id across solidity, cairo => and for UX perspective, we can allow user to request with raw string like STARKNET and SN_SEPOLIA.

update update SN_MAIN for mainnet staknet.

0x534E5F4D41494E 23448594291968334