Implement compiler executable

[bitwalker]

This issue is the final piece of #4 to have a complete compiler toolchain that can be used independently.

This executable basically puts together the following pieces of the compiler that we have built:

### Prereqs
- [ ] #22
- [ ] #14
- [ ] #29
- [ ] #24
- [ ] #18
- [ ] #27
- [x] Emit MASM files to disk as a bundle (IR, metadata, source maps)

In essence, the frontend of the compiler takes as input either a Wasm binary (.wasm), Wasm text format (.wat), or the HIR textual format (.hir) so that we can store/load our own IR. Regardless of input format, the frontend translates to the in-memory HIR representation, and then handles a request to compile or eval that input in some way. The following is a set of capabilities I expect the compiler to provide (both when used as a library and as an executable):

### Capabilities
- [x] Run the default release pipeline to emit a MASM bundle from the input sources. This release pipeline runs all of the analysis, transformation, and optimization passes, then emits the MASM via the codegen backend
- [x] Specify a specific set of compiler passes to run, emitting whatever the output of those passes are to the current target directory (e.g. if the passes produce optimized HIR, then HIR textual format would get emitted). We will use this in our `lit` tests to check that input IR gets transformed to the expected output IR when certain passes are applied.
- [x] Configure the desired level of optimization (and along what dimension, i.e. size vs speed). I think we'll provide the following optimization levels: `-Onone` (no optimization), `-O1` (default optimization that balances speed and code size), `-O2` (max optimization for speed), and `-Oz` (optimize for size). For the time being, we don't have much in the way of optimization passes, so this will only really apply once we start implementing some of those.
- [x] Configure what type of artifact to emit (executable vs library), and what to call it (if not specified, defaults to the name of the input file, or in the case of multiple inputs, the parent directory of those inputs if all from the same directory, falling back to the name of the current working directory if the inputs are in different directories)
- [x] Configure the target directory where artifacts will be emitted
- [ ] Configure where to search for any inputs needed by the linker (e.g. MASM libraries to link against/load metadata from, whether to include them in the final artifact, etc.)
- [ ] Run the input program using the MASM emulator for evaluation. This will also be used in our test suite, but will also be useful for interactive debugging of Miden IR.
- [ ] Run the input program using the Miden VM. This will also be used in our test suite

[bobbinth]

A couple of small questions/comments:

• What name were you thinking of using for the compiler executable?
• In the future, would it make sense to supply some of the options via a .toml file?

[bitwalker]

• What name were you thinking of using for the compiler executable?

The current name is midenc, but it's not set in stone. I don't have strong opinions about it as long as the name is short and easy to remember.

• In the future, would it make sense to supply some of the options via a .toml file?

We can certainly support that. clap even provides this out of the box I believe. I don't anticipate there being much to configure, at least initially, but there's really no downside to supporting it. We'll definitely want to have some kind of project config file for Rust projects that we compile to MASM, so being able to leverage that could be convenient.

[bobbinth]

The current name is midenc, but it's not set in stone. I don't have strong opinions about it as long as the name is short and easy to remember.

I think midenc works fine. btw, related to #20 - should we rename this repo to something like miden-compiler? Or maybe just compiler?

[bitwalker]

@bobbinth Yeah either miden-compiler or compiler works for me. The latter should be unambiguous in the 0xPolygonMiden namespace, so that might be the nicer option, but I'll leave that up to you.

[bitwalker]

This is almost complete, there are just a few small tasks remaining to close out this milestone, should be done this week.

[bitwalker]

Marking this completed