ZIR-153: Introduce directive to manually alias layouts

[jacobdweightman]

Introduce a new "compiler directive" language feature. These:

• affect compilation in a way that doesn't fit within the component abstraction
• can take arguments just like any other component
• do not construct any values
• are marked with a ! (like Rust macros) to make them stand out in the source code

The first directive, introduced in this PR, is the alias layout directive, which takes as input any two components of the same type (coercing along super chains if necessary), and causes the compiler to ensure that they are laid out in the same columns of the STARK trace.

For example (from alias_layout_hint_5.zir):

component Concatenate<N: Val, M: Val>(a: Array<NondetReg, N>, b: Array<NondetReg, M>) {
  result := for i : 0..(N + M) {
    in_a := InRange(0, i, N);
    [in_a, 1 - in_a] -> (
      NondetReg(a[i]),
      NondetReg(b[i - N])
    )
  };
  for i : 0..N { AliasLayout!(a[i], result[i]); };
  for i : 0..M { AliasLayout!(b[i], result[i + N]); };
  result
}

component Top() {
  a := for i : 0..4 { Reg(i) };
  b := for i : 4..8 { Reg(i) };
  Concatenate<4, 4>(a, b)
}

The Concatenate<N, M> component concatenates two arrays of registerized values. Without the AliasLayout directives, it places the concatenation in new columns, and thus requires 16 columns (4 for a, 4 for b, and 8 for result). With the directives, though, result shares the first 4 columns with a and the last 4 columns with b, for a total of 8.

Changes in this PR:

• introduce a new CheckLayoutFuncOp aspect which collects layout constraints (this conveniently also simplifies the data flow analysis that we need to do to generate correct layouts)
• add infrastructure for compiler directives
• add the AliasLayout directive
• add asLayout, lookup, and subscript utilities to ZhlComponent.cpp
• pass layouts as arguments to constructors

[jacobdweightman]

Added some performance enhancements that go a long way in counteracting the performance hit of adding this feature on the current draft of the Keccak accelerator. These are the numbers I ended up with on my machine for the "small test" (2897 cycles) in the interpreter:

Before: 106 s
After (no performance work): 402 s
After (with performance work): 209 s

I think there's a good deal more "easy" performance work, which I'd like to poke at next. I hope it might be possible to get another 2x from further parallelizing the compilation pipeline, but I'd like to move towards merging this soon.

[jacobdweightman]

Since the bulk of the time was spent canonicalizing for the interpreter, I just tried turning off that step which presumably results in us interpreting a lot more instructions, but skips that apparently expensive pass. On my machine, I just ran the short Keccak test in the interpreter in 74 seconds, which is about ~25% faster than before.

[shkoo]

Neat!

[jacobdweightman]

Pushed one more commit that fixes a regression in the v2 circuit; talked with Nils about an alternative approach, but we're going to merge now anyway and I'll follow up.