Better proc-macro for Step enums

[taikiy]

With this change, #[step] attribute macro expands to #[derive(Step)].

Step derive-macro will implement all necessary traits for both descriptive and compact gates. The new macro also adds two attributes obsolete and dynamic. You can annotate an enum variant as obsolete to make the macro ignore it while macro expansion. For those steps that are dynamically executed (i.e., BitOpSteps), you can use #[dynamic] attribute.

Currently, we use #[step] attribute macro to annotate step enums, and it expands to #[derive(Step)] derive macro. The reason for doing this indirection is that attribute macros allow enum-wide attribute like #[step(obsolete)]. Without this, we'd need to annotate each variant instead.

I've also made improvements to compile time errors to make them more actionable. Here are a few examples.

• A new step is added but the step is not found in steps.txt

error: ipa_macros::step expects an enum with variants that match the steps in steps.txt. If you've made a change to steps, make sure to run `collect_steps.py` and replace steps.txt with the output. If the step is obsolete, consider removing it or annotate the enum/variant with `obsolete` attribute.
  --> src/protocol/modulus_conversion/convert_shares.rs:51:12
   |
51 | pub(crate) enum ConvertSharesStep {
   |                 ^^^^^^^^^^^^^^^^^

• Enum name conflicts

error: ipa_macros::step found multiple enums that have the same name and contain at least one variant with the same names. Consider renaming the enum/variant to avoid this conflict.
  --> src/protocol/modulus_conversion/convert_shares.rs:51:12
   |
51 | pub(crate) enum Step {
   |                 ^^^^

[taikiy]

still have these until we output real-world-infra narrows to steps.txt

[akoshelev]

I wonder if making step attribute/macro very powerful is the direction we should pursue. It makes it convenient to write in the "happy" case, but makes it inflexible if custom step is required. I am also not in favor of generalizing #dynamic annotation - any step that requires less than or more than 64 elements would require a lot of customization or getting rid of step annotation completely. Same applies to automatically derived macros - leaving them out of scope for step derivation is the right thing to do imo.

[taikiy]

I think we can think of this one as the first iteration. I didn't want to add too many extra things, but I'll be happy to work on making it more flexible like #[dynamic(64)] or whatever appropriate. We seem to be happy with 64 elements for now though. As for the derives, I removed all traits except for the Step. I was thinking we at least need Clone, but turned out it isn't needed.

[taikiy]

BTW, I didn't use the unique-type-id crate since that uses an external toml file to manually assign IDs. Instead, the macro spits out an error when it detects a name conflict at compile time, letting the user know that the conflict must be resolved.

[akoshelev]

chatted in TPAC about it - while I remain concerned about step macro being too powerful and general concern about proc-macros debuggability/readability/maintainability, I think we should push this change. We realized that [#obsolete] attribute is no longer required as we track step transitions inside thenarrow and the remaining usages are inside the dead code only, so there will be less features for step macro.

I would also prefer to not use dynamic as the overhead of using repeat64str is pretty low compared to readability, but it is not the hill I want to die on.

@taikiy is going to clean up some dead code and unless someone objects, push this change