Add EthAccount

[ericnordelo]

Fixes #573

PR Checklist

• [x] Tests
• [x] Documentation
• [x] Added entry to CHANGELOG.md
• [ ] Tried the feature on a public network

[ericnordelo]

I also have some doubts on the EthAccount dual dispatcher. The v0 eth account pubkey used the felt252 eth address; whereas, this implementation uses the secp256k1point eth pubkey. Backward compatibility will be an issue. Do you agree?

I don't think we need to be BC with the cairo 0 version, but I'm wondering if we should add the camelCase interfaces for this module at all. A reason to keep it is that some contracts and modules can still be using isValidSignature, and this could be compatible by just passing a different signature (secp256k1 compatible). cc @martriay

[ericnordelo]

@andrew-fleming I've pushed the updates regarding error messages, after we confirm we are ok with it, I will update the rest in the other PR. The rules I'm following:

• Use assertion macros instead of inline functions (assert! and assert_eq!). These allow us to pass ByteArrays instead of short strings.
• Use assert_eq! over assert! when applicable.
• Avoid adding messages to assertions as much as possible to avoid redundancy. There are cases where messages are helpful, but sometimes they are redundant. for example, assert!(big_point_1 != big_point_2); shouldn't need a message while assert_eq!(parity, true, "Parity should be odd"); add some clarity.
• When the message is helpful, I'm following these short rules by basically using "X should be Y" or "X should have Y" or just "Should be/have Y", etc...

Let me know what you think.

[martriay]

We can fix the conflicts and merge.