Re-worked structure.member_t.refs() to also return structure operands that reference a defined global

[arizvisa]

So, the idaapi.get_opinfo does not return operand types where the operand is pointing to a defined structure. Because of this, the structure.member_t.refs() method does not act like one would expect. Until this PR was written, this method would only return references where the field was explicitly applied to an instruction's operand.

To accomplish this, another case was added to the member_t.refs() which walks through all the operands for each instruction, checks to see if any have an offset that can be calculated statically, and then tries to find the structure id at that given address. If so, then it is compared against a list of all possible structure ids that the particular member might point to. As a structure can be referenced inside other structures, this had to be manually collected in order to perform the comparison.

Additionally, in order to calculate the offset that the instruction operand is pointing to, the immediates from the operand need to be identified. As this can vary between the different operand decoders for each processor, the interface.namedtypedtuple class was modified so that accessing attributes is case-insensitive. This way only two attributes ("offset" and "address") need to be checked for existence in order to distinguish whether it is possible to calculate their target address statically.

The structure.structure_t.refs() method was also updated so that it would return any members that are referencing the structure. This was necessary so that the member_t.refs() method could be used to identify any structure that is referenced by said member.

Closes issue #33.

[arizvisa]

Wow, that was a huge fucking pain...