Added decoding for static references

[dkcumming]

Added decoding for static references:

• Changed reduce_to to keep the static items
• Decoding of statics added to decoding.py
• Added passing test for static references, and failing test for static pointers (to be followed up on in another PR)

[mariaKt]

Because statics have a symbol name, due to reduce_to now maintaining statics, they end up into the functions map as well.

Here is the path:

• reduce_to keeps the static item, so it appears in SMIRInfo.items (smir.py:94, indexed by symbol_name).
• function_symbols (smir.py:128) builds missing from ALL items.keys() not already in the functions table. The static's symbol isn't in that table, so it gets added and assigned a fake negative Ty (fake_ty = -2, -3, …).
  Now, every step that is followed for the functions (function_symbols_reverse, _functions), is similarly followed for the statics because they have a symbol, so they end up in the function map.

This is probably OK for correctness, because the negative Tys are never used as a call target, so the keys associated with statics are never looked up that way. But:

1. the function map is already large; there's no need to bloat it further with entries that are never used.
2. it's conceptually wrong: a static is not a function and shouldn't be in the functions map. While I see that they are both global objects and a common data structure with both can be useful (e.g., for addressing), I don't think that that data structure should be the functions map.

This can be addressed by restricting the missing computation to function items only, so only genuine functions get synthesized Tys, or another way if you prefer. Either in this PR or a quick follow-up, whichever is easier, no need to block this. It shouldn't affect the static decoding added by this PR, since it reads from the separate new statics property, not from the function map.

[dkcumming]

@mariaKt good catch with the function symbols and statics mix up, thank you.