This commit introduces a new data type to represent local variable
declarations. These are not currently attached to anything, but are used
downstream during code generation. The local identifiers are also used
in the in-crate representation of Miden Assembly, coming in a follow-on
commit.

This commit fleshes out the implementation of inline assembly that we
had essentially stubbed out prior to this. The following are provided as
part of this implementation:

* A representation of the Miden Assembly instruction set, in crate,
  with the ops we intend to support in the near term. This is used to
  represent the contents of inline assembly, and is also used in the
  upcoming codegen backend as the target IR for Miden Assembly, as it
  is a flatter representation similar to Miden IR. The intent is to also
  implement a tiny evaluator for this subset of Miden Assembly for use
  in tests without having to emit MASM files, and run the Miden VM which
  is much more expensive. It also allows us to track the subset of Miden
  Assembly which we support in the compiler, as well as represent
  experimental changes that have not yet been implemented upstream.
* `MasmBuilder`, which is constructed from an `InstBuilder` via `inline_asm`,
  and plays a similar role to `FunctionBuilder`+`InstBuilder`, but in
  terms of Miden Assembly, in the context of constructing a single inline
  assembly block.
* Improved pretty printing of inline assembly. Now, an inline assembly
  block is printed like so (this block adds the two inputs, and squares
  the result, which is returned as the result of the inline assembly
  block):

  ```hir
  asm (v1, v2) {
      add
      mul.2
  } : felt
  ```
* A generic data structure for use in representing the operand stack,
  and the common operations which are performed on it. This is used to
  validate inline assembly, as well as keep track of values during code
  generation. It will also likely be used for whatever evaluator we
  throw together for use in testing.

The [TypeRepr] enum is intended to represent how a specific [Type] will
be encoded in terms of field elements/words on the operand stack in
Miden. See the doc comments for details.

This is meant to provide a single source for information regarding type
layout in Miden. For types in linear memory, the encoding is slightly
different, as we must preserve the semantics of byte-addressability in
the IR. However, when placing values on the operand stack, the encoding
is modified to provide a more natural alignment between individual terms
and elements on the stack.

The specific representations in this commit are just an initial draft
based on details I'm aware of at this time, but we may make adjustments
as necessary.

The previous implementation did not provide us with an opportunity to
validate the state of the operand stack after the control flow
instruction is constructed. It also failed to account for changes to the
operand stack within the control flow instruction body.

This commit introduces a new implementation, one for if.true, and one
for the loop instructions, which provides a builder API for those
instructions. These builders ensure that upon construction, the operand
stack is consistent across all control flow edges leaving the
instruction, as well as checking other important invariants, such as
while.true requiring a boolean on top of the stack when entering/exiting.

This implements a function on `Type` called `is_compatible_operand`,
whose purpose is to determine if a type is compatible with another
type in the context of a binary operator. Type compatibility is
defined here in terms of what types can be implicitly coerced to
the controlling type of the operator safely.

For example, one can safely apply `u32.add` to `u32` and `u8`,
where `u32` is the operand whose type "controls" the expected
type produced by the operation. Similarly, applying `u32.add`
to `u8` and `u8` is safe, albeit with no guarantees about catching
overflow of the `u8` range, both operands are `u32` compatible. On the
other hand, applying `u32.add` to `u32` and `i32` is not compatible,
because `u32.add` does not handle signed integers, not to mention there
is no way to handle negative results.

This commit also has a couple small tweaks to how a few of the predicate
functions are expressed to suppress some clippy warnings.

This commit extracts out the handle of stack affects for the inline
assembly builders, and addresses a number of places in which the types
were either not validated, or were incorrectly validated/applied.