chore: pull across macro ordering changes

[TomAFrench]

This PR pulls across the changes from noir-lang/noir#6326 so we can see how it affects the aztec-nr macros.

[Thunkar]

Seems like a simple reordering of annotations makes this work (waiting for CI). One thing that I found curious:

    #[event]
    #[derive(Serialize)]
    struct ContractInstanceDeployed {

^^^ that fails, while this works:

    #[derive(Serialize)]
    #[event]
    struct ContractInstanceDeployed {

Makes sense, since #[event] injects a trait that expects the attached struct to implement Serialize. I tried to do this inside the #[event] macro:

    let any = fresh_type_variable();
    let maybe_serialize_impl = typ.get_trait_impl(quote { protocol_types::traits::Serialize<$any> }.as_trait_constraint());

    assert(maybe_serialize_impl.is_some(), "A nice error message to convey #[derive(Serialize)] must come before #[event]");

And to my surprise, maybe_serialize_impl always has a value (even with the incorrect annotation order). How come?

[TomAFrench]

Ah excellent! Much easier than I feared.

[TomAFrench]

Hmm, I'm not entirely sure why there would be an impl in that case. @jfecher can you shed light here?

[jfecher]

@Thunkar

#[derive_via(derive_serialize)]
trait Serialize<let N: u32> {}

comptime fn derive_serialize(s: StructDefinition) -> Quoted {
    let t = s.as_type();
    quote[impl Serialize<0> for $t {}]
}

#[find_serialize]
#[derive(Serialize)]
struct Foo {}

comptime fn find_serialize(s: StructDefinition) {
    let any = std::meta::typ::fresh_type_variable();

    let serialize = quote { Serialize<$any> }.as_trait_constraint();
    let serialize_impl = s.as_type().get_trait_impl(serialize);

    assert(serialize_impl.is_some(), "#[derive(Serialize)] must come before #[find_serialize]");
}

Errors as expected for me