Type system redesign

[lucas-rami]

Tracking issue for the type system redesign, described in this specification.

• Define new types: handshake::ChannelType and handshake::ControlType (bebfb02).
• Define new operations to manipulate these types: handshake::UnbundleOp (9fef8a5), handshake::BundleOp (9fef8a5), and handshake::ReshapeOp (6db1062).
• Redefine arith operations in Handshake to make them accept our custom types (9dbd9db adds a usable subset of the arith operations, implementation of currently missing operations is moved to a different issue: [Handshake] Add Handshake versions of missing arith/math operations #102).
• Refactor significantly the CfToHandshake conversion pass.
  • First, a largely mechanical makeover (without using the new types) to avoid a MLIR dialect registration issue that arises non-deterministically when running it (582684a).
  • Then, add type conversion logic to make it convert MLIR's standard types into our custom types (3aadbaf).
• Adapt all of our existing passes to the new type system (3aadbaf).
• Refactor the Handshake-to-HW lowering flow.
  • Add Handshake post-processing pass(es) that manipulate our types to make the conversion to HW and then RTL export easier (2082b20).
  • Remove type conversion infrastructure from the HandshakeToHW conversion pass (now handled by the CfToHandshake conversion pass) (3aadbaf).
  • Add HW post-processing pass(es) to unbundle all channels into their individual signals (this will make the RTL export logic simpler) (moved to [Backend] Unbundle dataflow-types into individual signals before RTL export #139).
• Backend changes.
  • Most likely we will need to be able to fully encode a channel's characteristics in RTL parameters. Support for more complex RTL parameters that the ones we already have needs to be added (4e1c39f).
  • Define new components which are able to support more complex channels (moved to [RTL] Define modules which support extra channel signals when possible  #140).