[Emit] Organize output files using the emit dialect

[nandor]

No description provided.

[mikeurbach]

The rationale and usual dialect boilerplate look good to me. A couple minor questions on the implementation, but looks like a great start.

[mikeurbach]

It looks like FileOp and FileListOp are expected to be siblings that exist within the same level of SymbolTable. Should we write that down in the ODS description? Could we go farther and maybe use HasParent with the same kind of op for both? Or do we not care, as long as their siblings?

[nandor]

HasParent is tricky since at the FIRRTL level these should live inside of a CircuitOp, but at the HW level they live inside a ModuleOp.

[mikeurbach]

Makes sense. I guess we should just document in FileListOp that it expects the FileOps it references to be in the same symbol table as the FileListOp itself.

[darthscsi]

It should fail if it's not. The lookup should be structure to ensure that, which might mean not poking at random op parents to do lookup but following the symbol lookup rules.

[mikeurbach]

This looks good to me now using lookupNearestSymbolFrom(getOperation(), ...)

[darthscsi]

Looks good. Given the issues we've had, should be checking symbol nesting validity with explicit tests.
I'm not sold on emit.verbatim making sv.verbatim redundant. A generic emit.verbatim does make sense, but I worry about dialect-specific substitution semantics.

[darthscsi]

It should fail if it's not. The lookup should be structure to ensure that, which might mean not poking at random op parents to do lookup but following the symbol lookup rules.

[mikeurbach]

My previous concerns are addressed, just some questions about the optional symbols.

[seldridge]

Generally, I'm good with this. This will do wonders to help wrangle all the various files that come out of a build.

There are some design point considerations around if a filelist op is actually needed. I don't have a super strong opinion here.