Initialize support for silica function translator

[leonardt]

This PR tracks an effort to provide support in the Silica compiler
for compiling pure Python functions to Verilog. This leverages
the existing Verilog backend used by the coroutine compiler
pipeline. There's still some work to clean up and organize how
we're doing this, but this serves as a minimum working example.

[coveralls]

Pull Request Test Coverage Report for Build 373

• 71 of 79 (89.87%) changed or added relevant lines in 6 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.7%) to 69.367%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
silica/function.py	48	49	97.96%
silica/type_check.py	7	9	77.78%
silica/width.py	6	11	54.55%

Totals
Change from base Build 362:	0.7%
Covered Lines:	1841
Relevant Lines:	2654

---

💛 - Coveralls

[hofstee]

Looks like a reasonable start to me - should we try to get this into magma rather than silica? It could be useful for circuit.combinational.

[hofstee]

Why do we need to_type_str instead of just putting the type in the type_table?

[leonardt]

I think right now my plan is to keep any Python -> Verilog related code in silica since we have the verilog backend here already. If we move this to magma (which I'm not opposed to), we'll need to migrate a lot of code, so I think we should think/discuss the overall system/package/module architecture before investing in the migration.

My initial thought is that a generic Python -> Verilog translator would be a useful tool for higher level DSLs being built on top of magma (Silica is just one instance of that), so that would motivate factoring this logic into magma or some other independent package.

[leonardt]

The to_type_str issue is independent of this PR, but I think that's an artifact of the evolving code base. I think we can refactor the type/width logic to just use a type table with the actual type contained as the value, rather than separating the two (since the type holds the information to provide the width). I think originally I had separate types for magma/silica, but I realized I was essentially building the magma type system so I switched back to just using the magma types.