Link IR

In the work for #861, I'm wanting to generate IR externally and smash it into the current package. This is not so different from linking, but right now XLS does not have a linkage model. It would be useful to support multiple compilation units and linkage. Here are some thoughts:

- We need some way to handle symbol collision. One approach that I'm currently using for #861 is just to rename things that collide, but this is problematic for a general linker- you need to keep track of name updates, things become order dependent, code size could blow up, etc.
- Something like weak vs. strong symbols are needed for the way DSLX's parameterization is currently represented in IR. Parameteric IR would avoid this (but we don't like parametric IR?).
- We need some way to find named entities. It could be an import path in the IR. It could be a set of paths given to the linker invocation.
- Should things be imported before use? Should we have e.g. `extern fn foo(u32, u32) -> u32`?
- We need to decide the granularity of an "object file". For example, you could imagine that a single dslx -> IR conversion invocation producing a single IR "object file" (like C++). You could also imagine a single dslx -> IR conversion invocation producing multiple IR files, one file per proc (in this world, procs would encapsulate their channels and spawn other procs in IR). This approach is more like Java, and you could similarly make finding the path to an object file implicit based on the name of the object. This mirrors the way DSLX deals with imports.
- Should all optimization be performed only on post-linked IR?