address!: Add custom PartialEq impl

[febo]

Problem

In some cases, comparing addresses ([u8;32] arrays) with the equality operator (==) results in "bloated" code, which eventually leads to an increased CU consumption.

Solution

This PR adds a custom PartialEq implementation to Address, which compares its value as a sequence of u64 values.

[joncinque]

Looks good!

There was a comment in p-token about not using it in one particular place: https://github.com/solana-program/token/pull/90/files#diff-d65a3839b162d49521160ef473d81b3965eedffa48c0b7434ee324993951805aR13

Is the idea that this is better in almost all situations, but in rare cases it will be faster to use the auto-derived implementation?

[febo]

Looks good!

There was a comment in p-token about not using it in one particular place: https://github.com/solana-program/token/pull/90/files#diff-d65a3839b162d49521160ef473d81b3965eedffa48c0b7434ee324993951805aR13

Is the idea that this is better in almost all situations, but in rare cases it will be faster to use the auto-derived implementation?

Probably, I only found that one place that was worse in terms of CU. I think it is difficult to tell since it all depends on what optimizations the compiler is doing. We will be able to "access" the default one by doing p1.as_array() == p2.as_array().

Lucas is having a look at what the compiler is doing wrong on the default ==, so it might be the case that we won't need the custom implementation in the future.

[rustopian]

Looks good here.

EDIT: #345