slither-check-upgradeability: support complex datatypes

[webthethird]

Addresses #185, an old one, but still an issue!

Resolves false positives when comparing storage layouts that use structure types (test contracts and updated CI test included).

Currently only addresses structures, but I can add more here to resolve comparisons between other complex types, i.e., contract types and enums. (edit: Contract types also supported, at least on a superficial level, i.e., using the current Contract.__eq__() method which only works when comparing a contract object to another contract's name)

[webthethird]

@montyly @0xalpharush got any advice re: how to fix these failing checks? It seems like the pip-audit may be unrelated to the content of this PR, since I'm suddenly getting the same issue on #1506 (this check was passing before). As for the Features and Printers tests, it's not immediately clear to me why these are failing, though they seem to be possibly related to recursively nested structures. I just don't understand how the __eq__() method I implemented would affect those, when there's no equality comparison being done.

[webthethird]

Alright, my last commit resolved the infinite loop issue with recursively nested structures, but I still don't get why the printers test is failing. I tried commenting out my __eq__() implementation entirely and running ci_test_printers.sh without it, but the test still fails with the following error message:

Printer failed
functioncall-0.5.3.sol-0.5.17-compact.zip

[webthethird]

@0xalpharush @montyly my latest commit resolved the printer test issue (which was related to the human-summary printer and one of the detectors failing to hash a Structure object). This time the slither-read-storage test inexplicably failed to install Ganache, and of course pip-audit is still failing, though I saw that there's a separate issue now to fix the latter. Anyway, I'm pretty confident that all issues related to my code additions have been resolved.

[montyly]

I think this might create issue where two types share the same name

For example in

struct St{
	uint a;
}

contract A{

	St s;

}

import {A} from "test.sol";

struct St{
	uint b;
}

contract B is A{
	St s2;
}

Maybe we should create a canonical_name for type that would include the source mapping definition? (cc @smonicas @0xalpharush)

[webthethird]

Seems like canonical_name would be a good idea. But in the example you gave, wouldn't it be correct to say that the two St structs are not equal? In the highlighted code, while enumerating the elements of the two structs, the other_elem.name != elem.name would cause my __eq__() implementation to return False, which seems correct at a glance. Granted, comparing canonical names would probably be better still.

[webthethird]

I suppose if you renamed St.b in the second code block to uint a, then the resulting equality might be considered a false positive, since it would see that both structs have the same name, and their elements have the same types and names, therefore returning true. But that seems quite picky, since the two structs would be identical except for where they are defined in Solidity.