Use `GenesisConfig` in integration tests

It would both simplify and speed up integration tests if we didn't have to fund the accounts at the beginning of each test. For example, for the swap tests, instead of:
1. Issue assets from faucet A, claim from wallet A
2. Issue assets from faucet B, claim from wallet B

We could simply specify the genesis state to include the two faucets, as well as pre-funded wallets A & B with the relevant assets. This is what @drahnr's https://github.com/0xMiden/miden-node/pull/1000 allows.

I started experimenting with this specifically for the swap, and encountered the following challenge:
The account files generated during genesis are static, i.e. the client doesn't write back state updates into them (at least not out of the box).
This means that tests are not idempotent:
- we cannot re-use the same accounts across multiple test (or even test runs for the same test), because the client will load the genesis account state, while the chain has registered a new state
- we cannot test for absolute balances, but would need to refactor the tests to check for balance deltas instead

I see a few options around this:
1. Do not use genesis config, keep tests as they are
2. At the end of each test we write the updates to the relevant account `.mac` files. This still means our tests need to check for balance deltas instead of absolute values, but maybe that's ok. Also, if we start with 1000 A in an account and run the swap test repetitively, eventually we will run out of tokens to swap.
3. Generate an account for each test separately at genesis. This could be something like `.mac`, `.mac`. Tests will know how to load the account meant for them. We can stick with checking absolute values within a single run, but running the test multiple times requires checking deltas.

Note that using `GenesisConfig` is purely opt-in for the existing tests. I would really like to dogfood those changes, but at the same time having idempotent tests is important.

I think option 2. + 3. should be a good compromise. We can set the initial amount to be very high so anyone would be unlikely to ever run the same test locally enough times to run into problems (this resets with `make start-node`)