Add the test that executes counter contract and note script on the testnet

[greenhat]

Close #554

This PR:

• adds a new counter contract test executed against the Miden testnet using the client directly;

TODO:

• fix the TransactionProvingError(ProvenTransactionBuildFailed(AccountUpdateSizeLimitExceeded { account_id: V0(AccountIdV0 { prefix: 13040896844101492496, suffix: 497889488833280 }), update_size: 72217 })) error
• load the note's MastForest::advice_map into the advice provider before the execution Load account and input note MastForest::advice_map before execution miden-base#1452

[greenhat]

@bitwalker I've tried to use Scenario type for the counter_contract test on the testnet, and I stumbled on one lacking feature. When I want to get the note ID when I'm creating the output note so that I can use it later when consuming the note. I haven't figured out an ergonomic way to implement it with its builder-like API. So I temporarily wrote a new test using the Miden client directly.

Besides that, I've been thinking about the target audience for the testing harness, and I think it might be too opinionated for the end users. Meaning that they would have to familiarize themselves with Miden client API anyway when they will be writing their off-chain code. And now we are forcing them to also learn an opinionated framework to write their tests instead of just letting them use the already familiar Miden client API that they've used in their off-chain code.

[bitwalker]

@greenhat To be clear, the testing harness in the integration test suite is for internal use only, the public test harness would almost certainly look different, and likely incorporate the efforts by the node and client teams in terms of describing test setup/scenarios.

If the Scenario type isn't achieving the goal of allowing us to declaratively express test scenarios at a high level, while hiding the boilerplate/details of the underlying client orchestration, then it isn't suited to its purpose, and I think it should be rewritten/refactored so that it does. I still think writing tests directly against the miden-client APIs in our integration test suite is far too low-level at this point in time, and is going to cause a lot of churn as that API evolves. Ideally we could keep that churn contained in a single place, more or less, but it really depends on if there are repeated patterns in the tests.