[Feature]: Implement Arbitrary for Account and Possibly for Contract<T>

[0xNeshi]

What is the feature you would like to see?

This is so that devs can generate random Account in proptests.

If a dev wants to use Account in a proptest, then they surely know what they're doing and why, and they're willing to pay the performance price.
They can always instantiate Account in a proptest by simply:

• generating random string or bytes
• passing that to Account::from_seed or Account::from_seed_slice

They could even call Account::random() on each proptest cycle.

We should implement Arbitrary simply as a utility for devs.

---

Also investigate whether it makes sense to implement it for Contract<T>.

Cons:
Take the example of ERC20 contract, how do you define an arbitrary ERC20 contract?
It is surely deployed at a random address. Should it also have arbitrary storage state? Should the arbitrary storage state just be whatever is generated by the machine? Then we might often get a situation where individual token balances don't match total supply. Does it make sense to test against this?
Ok, you may say, we will create arbitrary storage state given meaningful constraints. But we cannot know which contracts the user will try to test, so we cannot set any type of constraints.

Pros:
The main critique for implementing this for Contract<T> is that we cannot know which constraints to use. We could circumvent this simply by implementing Arbitrary only for those Contract<T> where T already implements Arbitrary.That way we allow devs to instantiate a Contract<T> in a proptest if they so wish, and we move the responsibility for setting generation constraints onto them. If they don't like this, they shouldn't be randomly generating a Contract<T> storage anyway.

Contribution Guidelines

• I agree to follow this project's Contribution Guidelines