Allow complex contract signature schemes in wallet.Account

[fyfyrchik]

Close #3015

Implement second option from #3015 (comment)
In the first one (interface instead of wallet.Account) we still have a problem with network fee calculation: actor modifiers are executed after network fee is calculated and there are no hooks to change invocation script.

This implementation disallows providing signature as an argument (though in a backward compatible way).
It is a restriction, but not a sad one: if we have a private key, we can always add a simple signer and provide its address to verify(), which can use runtime.CheckWitness to effectively perform the same check (with proper scopes it could be exactly the same).

Also, not sure about the meaning of CanSign, so didn't touch it here.

TBH I would remove func argument in the NewContractSigner in neotest, it introduces a subtle dependency on the condition order in SignTx. Other option is to provide an integer but it is also a bit annoying. As an example, there is wallet.NewContractAccount which can be used instead of notary.FakeContractAccount in complex cases and which could be reused in tests.

We have 2 similar usecases for complex Verify scenarios, and in every in test we use constant arguments, could be more concise:

s := neotest.NewContractSigner(e.Hash, func(*transaction.Transaction) []any { return []any{acc.ScriptHash()} })
// could be
s := neotest.NewContractSigner(e.Hash, acc.ScriptHash())

Initially I wanted to add type-safe VerifyAccount constructors to rpcbinding but is doesn't provide much benefit compared to effort taken.

[AnnaShaleva]

A really nice one, and I like the contract signer simplification. With this PR it would be easier to implement #2670, so maybe we can include #2670 to our nearest plans, @roman-khimov, what do you think?

[roman-khimov]

#2670 is good, but we still have some better ones in the queue. Let's discuss this after 0.105.0 release.