bug fix(starknet): Fully-qualify prelude types in contract codegen. - #10137

Summary

The #[starknet::contract] plugin now fully-qualifies the prelude types it
emits in generated code (core::array::Array, core::array::Span,
core::option::Option, plus Option::Some/Option::None and
core::array::ArrayTrait::new) instead of relying on the bare prelude names.

Touched codegen sites:

• derive/event.rs — struct & enum Event impls (append_keys_and_data /
  deserialize) and the flat/nested variant deserialization.
• entry_point.rs — entry-point wrapper signature (Span) and ArrayTrait::new.
• dispatcher.rs — forward-method wrapper signature (Span).

Adds a regression test (shadowed_prelude_types) covering a contract that
defines Array, Span, and Option user types, and regenerates the affected
plugin_test_data golden files.

Type of change

• Bug fix (fixes incorrect behavior)

Why is this change needed?

Cairo has a single flat namespace, so a user type defined inside a contract
module that shares a name with a prelude type shadows that prelude name. Because
the generated code referenced the bare names (e.g. Array<felt252>), a user
struct Array {} (0 generic params) made the generated Array<felt252> resolve
to the user struct, producing:

error[E2163]: Expected 0 generic arguments, found 1

This happened even for a storage-only contract with no entry points — the
auto-derived empty Event impl alone references the bare prelude types. The
diagnostic gave no hint that the user's type name was the cause.

Fixes #10128.

What was the behavior before?

#[starknet::contract]
mod c {
    #[storage]
    struct Storage {}
    struct Array {}
}

failed to compile with error[E2163]: Expected 0 generic arguments, found 1
(same for Option and Span).

What is the behavior after?

The contract compiles. Generated code fully-qualifies every prelude type it
references, so a same-module user type sharing the name can no longer shadow it.

Additional context

Removing the bare reference also surfaced a now-redundant
use core::array::ArrayTrait; in cairo_level_tests/l2_to_l1_messages.cairo
(it was only being consumed by the previously-bare generated ArrayTrait::new()),
which has been dropped.

This is scoped to the prelude-type axis named in the issue and is distinct
from parameter-name collisions (e.g. __calldata__, component,
serialized, value).