feat!: init storage macro

[Thunkar]

Closes: #3198, #2928

Requires #4135, which is blocked by noir-lang/noir#4124

Automatic storage initialization via aztec macro.

Full support of public and private state from dep::aztec::state_vars::*, including Maps (and nested Maps!)
Limited support for custom types (as long as they have a single serializable generic and their constructor is ::new(context, storage_slot).

Pending: better errors, code comments and some cleanup.

Hijacking my own comment for the explanation:

The idea behind this is that in 99% of cases, storage initialization (that is, the impl for a given struct Storage... is redundant, and the only need for its existence was assigning storage slots...which in turn were necessary because we didn't know how to serialize the data structures that were used in a given contract or how much space they used once serialized (relevant for the public state).

After #4135 is merged, both of those things don't have to be explicitly provided since we're using traits, so the aztec macro can infer the implementation of the Storage struct just by taking hints from the definition. An example:

    struct Storage {
        // MyAwesomeStuff implements Serialize<2>, so we assign it slot 1 (and remember that it will take 2 slots due to its size)
        public_var: PublicState<MyAwesomeSuff>, 
        // Right after the first one, assign it to slot: current_slot + previous_size = 3
        another_public_var: PublicState<MyAwesomeSuff>,
        // Private and Public state don't share slots since they "live" in different trees, but keeping the slot count simplifies implementation. 
        // Notes also implement Serialize<N>, but they only take up 1 slot anyways because of hashing, assign it slot 5
        a_singleton: Singleton<ANote>,
        // Maps derive slots via hashing, so we can assume they only "take" 1 slot. We assign it slot 6
        balances: Map<AztecAddress, Singleton<ANote>>,
        // Slot 7
        a_set: Set<ANote>,
        // Slot 8
        imm_singleton: ImmutableSingleton<ANote>,
        // Slot 9. 
        profiles: Map<AztecAddress, Map<Singleton<ANote>>>,
    }

We have all the info we need in the AST and HIR to build this automatically:

impl Storage {
    fn init(context: Context) -> Self {
        Storage {
            public_var: PublicState::new(context, 1), // No need for serialization methods, taken from the the trait impl
            another_public_var: PublicState::new(context, 3),
            a_singleton: Singleton::new(context, 5),
            // Map init lambda always takes the same form for known storage structs
            balances: Map::new(context, 6, |context, slot| { 
                Singleton::new(context, slot) 
            }),
            a_set: Set::new(context, 7),
            imm_singleton: ImmutableSingleton::new(context, 8),
            // A map of maps is just nesting lambdas, we can infer this too
            profiles: Map::new(context, 9, |context, slot| { 
                Map::new(context, slot, |context, slot| { 
                    Singleton::new(context, slot) 
                })
            })
        }
    }
}

...as long as we use "canonical" storage implementations. This means AStoragePrimitive<SomethingSerializable> and Map<SomethingWithToField, AStoragePrimitive<SomethingSerializable>>.

TLDR: define the Storage struct, in 99% of cases the macro takes care of the implementation!

Implementing custom storage will look just like it does know, the macro will skip automatic generation if it finds one.