Fix a few issues in the mem2reg interface implementations of VariableOp,
ReadOp, and BlockingAssignOp. Add tests reduced from the Snitch core
that used to fail before this fix.

* add calyx canonicalization.

* Added more checks to calyx.component, fix some details.

* update CmakeLists.txt.

* Update lib/Dialect/Calyx/CalyxOps.cpp

Optimized code.

Co-authored-by: Chris Gyurgyik <[email protected]>

* Update lib/Dialect/Calyx/CalyxOps.cpp

Optimize error reporting.

Co-authored-by: Chris Gyurgyik <[email protected]>

* use clang-format and add calyx.par test.

* Optimised code.

---------

Co-authored-by: Chris Gyurgyik <[email protected]>

Initialize `VariableOp`s of a four-valued type with a zero. This is in
line with the rest of `MooreToCore` which maps all X/Z to zero at the
moment, either implicitly by mapping to `comb.*` ops, or explicitly by
conjuring up zero constants.

Add a lowering pattern from `moore.conditional` to `scf.if`. This
currently relies on the condition being a two-valued integer after
lowering. Once we support four-valued integers at the core dialect
level, the lowering of `moore.conditional` will become a lot more
complicated.

Add a conversion for `moore.casez_eq` and `moore.casexz_eq` operations.
These only really make sense if the operands are four-valued integers,
since the X and Z bits indicate which bits to ignore during the equality
check. We don't have support for four-valued integers in the core
dialects yet. However, the vast majority of uses of this op are
comparing an SSA value against a `moore.constant`. This case we can
handle properly by looking at the constant, identifying the unknown
bits, and then masking them before performing a regular two-valued
comparison between the two operands.

Add an operation that delays the propagation of value changes from its input to its output.
This allows mem2reg of LLHD signals with a unique driver with a delay.
For example
```
%sig = llhd.sig
llhd.drv %sig, %val after <1ns, 0d, 0e>
%res = llhd.prb %sig
```
can become
```
%res = llhd.delay %val by <1ns, 0d, 0e>
```

LLHD's `reg` operation dates back to when the `seq` dialect was not a thing yet. It has the disadvantage that
* it only works with `inout` values
* while it can model all kinds of registers and latches you can think of, more than is actually used/necessary in practice, it is very complicated to work with

Instead of having this operation, we can
* use the seq registers
* if we need to work with inout values, we can continuously drive the seq register output to the signal with an additional `llhd.drv` operation
* If some state element occurs frequently for which we don't have an operation in the seq dialect, we can add one there specifically for that kind of element (e.g., a latch?)
* the `lllhd.reg` operation can specify triggers with different clocks. The most common case are async resets which we also support in the seq dialect. Other, more weird constructs could also just be left in the `llhd.process` based representation. We need to support them in simulation and verilog export anyway. Alternatively, we could also decompose it to the bare logic gates with feedback loops directly, don't know why that would be necessary though.

Users want to know what constants were used in a design. Plumb them through using the manifest. No runtime support, no pycde support.

Cleanups to the manifest as well. Update the runtime to support the schema changes to the manifest.

…ion (#7491)

The `CreateSifiveMetadata` pass was creating hierarchy paths to the memory
 module pre-extraction. The `om.path` was being updated as the memory was
 extracted in the following passes. But recently we realized this was a bug,
 as the downstream tools consuming the metadata files, were actually expecting
 the pre-extraction hierarchy paths to the memory.
This PR fixes the path, to terminate at the parent of the module that
 instantiates the memory and encodes the pre-extraction memory instance as a
 string. The tool that will parse the final `mlir` must now construct the
 actual pre-extraction path from the two lists, by appending the pre-extraction
 instance name to the path.

Access per-module constants from the ModuleInfo class.

- Don't check the type compatibility until `connect()` time.
- Account for the extra symbols.

This operation produces a list by concatenating lists of the same
type. The operation definition and a simple round trip test have been
added. This is used to compose lists, which is a key feature to enable
hierarchical composition of OM values.