Enable concurrent fee collection

[janezpodhostnik]

This PR enables concurrent fee collection by introducing child fee accounts that can collect transaction fees in parallel, reducing contention on the single FlowFees vault during high-throughput scenarios.

Changes:

• Child Fee Accounts: Fees are now distributed across multiple child accounts using getTransactionIndex() % numChildAccounts, allowing concurrent deposits without vault contention
• Updated getFeeBalance(): Now aggregates balances from the main vault plus all child fee accounts
• Updated withdrawTokensFromFeeVault(): Withdraws from the main vault first, then iterates through child accounts if more funds are needed
• New collectFeesOnChildAccounts() function: Routes deposited fees to the appropriate child account based on transaction index
• New transaction add_fee_child_accounts.cdc: Allows creating and registering child fee accounts

Falls back to the original single-vault behavior when no child accounts are configured, ensuring existing deployments continue to work.

Missing:

• Fix for the cadence code checker
• check epoch transitions work normally

[joshuahannan]

I assume the purpose here is to have many different fee accounts so that depositing fees to the service account doesn't cause conflicts that would prevent concurrent execution, right? How many accounts do we think we would have and is that configurable based on network load or something?

[janezpodhostnik]

@joshuahannan We can add as little or as many child accounts as we want. The number on child accounts affects how many transactions we can theoretically execute concurrently (if they had no other conflicts). The traffic that is currently on mainnet has small blocks and a significant amount of collisions within blocks. With that in mind I don't think we will not need more than 5 child accounts for a long time.

If the blocks become larger, and the transactions more independent, we can add a few child accounts.

Without code changes in the FVM the theoretical maximum for now would be 256.