Remove proc inlining

[grebe]

Proc inlining as currently envisioned is complex, needs to re-implement some of what codegen does, and in many cases produces procs which cannot be pipelined well.

With multi-proc codegen #950 coming, many of our current proc-inlining usecases can be ported to use multi-proc codegen.

Ideally, we will remove proc inlining and replace it with smaller, easier-to-understand replacements. For example:

• cross-proc optimizations that move logic across channels could (where safe) partially inline procs
• Proc inlining uses "valid-only" channels that do not backpressure, in cases where we want this for QoR we could add new channel types and use them in a multi-proc setting.
• Codegen that supports multiple pipelines could essentially inline multiple procs more simply than how proc inlining works.

[rw1nkler]

What about the situation when you have a proc interacting with RamModel, that instantiates two sub-procs - one for reading, and one for writing to the memory. I believe that the top-level proc, as for now, has to be inlined, otherwise the RAM rewriting step will fail, because only half of the interface is available for each child proc. (see the discussion started by https://github.com/google/xls/issues/1455#issuecomment-2193983042)

[grebe]

Proc inlining shouldn't be needed if you multi-proc codegen the same top-level proc- the idea is that multi-proc codegen will have the same interface at the top, but instead of inlining all procs into one module, it will separately instantiate each proc as sub-modules.