Tracking issue: Type hints

[patrick-rivos]

Type hints are very helpful when reading/refactoring/debugging code. They can help show issues without running the code, and highlight edge cases before they're ever executed.

Notes:
Q: Why wrap imports in an if TYPE_CHECKING: statement?
A: Otherwise, we get circular dependencies. Since types aren't actually used at runtime, imports can be safely gated so they're only included when type checking.

Q: Why not annotate return types?
A: The derived return types include things like None, which people are often tempted to omit when typing a function. Allowing MyPy to derive the types on its own ensures we are being honest and get warned when a function's output does not match our expectations.

Q: How do you determine the type to annotate with?
A: I use existing comments, search the codebase for call sites, and print(type(x)) when I'm really lost. It's a best guess, so I may need to update some types as more of the codebase is annotated.

Directories to add type hints to:

• src/microprobe
  • code Add type hints to src/microprobe/code folder #38
  • driver
  • model Add type hints to src/microprobe/model folder #48
  • passes
  • schemas
  • target Add some type hints to src/microprobe/target folder #42
  • utils
  • other files in this dir
• targets
  • generic Add some type hints to target/generic folder #49
  • powerpc
  • riscv

[rbertran]

Base on the discussion we had here, I'd update this issue to add another a couple of items:

• Run the mypy as a CI step in Travis to perform static type check validation
• Enable typeguard during the execution of the CI tests to perform dynamic type check validation during tests (ensure we do not affect production code performance)