feat: add ISA specific setting instrument_inst for zkASM

[mooori]

• Adds the ISA specific instrument_inst setting for zkasm.
• Adds ZkasmSettings to handle ISA specific settings in zkasm_codegen.

Can be reviewed commit by commit and commit messages provide a summary of the changes.

Context

Benchmarking infra will use the instrument_inst setting to enable instruction tracing. I propose to add this in a separate PR.

Enabling instrument_inst

It is disabled by default. To see the changes introduced by this PR in action, it can be enabled with the following patch:

diff --git a/cranelift/filetests/src/test_zkasm.rs b/cranelift/filetests/src/test_zkasm.rs
index 63086e228..6ac7818ec 100644
--- a/cranelift/filetests/src/test_zkasm.rs
+++ b/cranelift/filetests/src/test_zkasm.rs
@@ -60,7 +60,8 @@ mod tests {
 
     fn test_module(name: &str) {
         let module_binary = wat::parse_file(format!("../zkasm_data/{name}.wat")).unwrap();
-        let settings = ZkasmSettings::default();
+        let mut settings = ZkasmSettings::default();
+        settings.instrument_inst = true;
         let program = zkasm_codegen::generate_zkasm(&settings, &module_binary);
         let expected =
             expect_test::expect_file![format!("../../zkasm_data/generated/{name}.zkasm")];

Then instrumented zkasm can be generated by running a test like:

env UPDATE_EXPECT=1 cargo test --package cranelift-filetests --lib -- test_zkasm::tests::add --nocapture

[aborg-dev]

Overall, looks good to me!

I would probably go with a more specific name for the option like emit_profiling_info as the current instrument_inst does not clearly show the purpose without reading the documentation.

[aborg-dev]

(just an opinion, no expectation to change anything)
I see the reasoning for having a dedicated function if we have more settings in the future, but at this stage, I would call this a premature optimization and follow YAGNI (You aren't gonna need it) [1], [2].

[1] https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
[2] https://martinfowler.com/bliki/Yagni.html

[mooori]

Adding a separate handle_zkasm_settings function also aims at encapsulating functionality and avoiding that generate_zkasm(...) grows too big. I think the separate function does not add any significant overhead here. No strong opinion on my side, merging now to wrap up the PR.